← Prev in month ← Prev in thread
Next in thread → Next in month →

Core 09 RE: Action Items.

From
Phillip Hallam-Baker <>
Date
2001-06-20T17:57:35+00:00
ID
Thread
Core 09 RE: Action Items.
Title: RE: Contradictory requirements?

As 
promised a further revision with the following changes:

 

1) 
Added Eve and Dave to the credits (which does not necessarily imply 
endorsement).

 

2) 
Have added some nice pretty diagrams, showing the class structure of the 
assertions and query structures respectively. The notation I used is a variant 
of Rumbaugh which I adapted to take account of the subtly different XML data 
model.

 

3) 
Have broken out the Query structure into a sequence of abstract types and three 
possible query types. Note that the Respond element is still present 
although some of the functionality is now redundant.

 

        
Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal 
Scientist
VeriSign Inc.

781 245 6996 
x227

  
-----Original Message-----
From: Phillip Hallam-Baker 
  [mailto:]
Sent: Wednesday, June 20, 2001 11:47 
  AM
To: ''
Subject: 
  Action Items.

  
At the focus I 
  said I would provide a rationale for the query and assertion structures, 
  however during the conference call thinking on the query structure appeared to 
  go in a different direction and so instead I will provide the rationale for 
  the query structure that appeared to be suggested at the 
  meeting.

  
 

  
Principles:

  
 

  
1) You only get 
  what you ask for

  
So if you ask for an Attribute assertion you should 
  not recieve back an Authorization Assertion.

  
 

  
2) Support 
  different toplevel query elements for each of the assertion issuer 
  types.

  
The main advantage of this is that it allows a 
  service to advertise that it supports Authorization Assertions by means of 
  WSDL like description.

  
 

  

  
3) Support legacy 
  applications

  
It is essential that an existing legacy authorization 
  engine be able to support SAML without major revision to the 
  code.

  
 

  

  

  
4) Permit some level of formal 
  definition

  
Although we will not specify the implementation 
  architecture we may specify the behaviors of the system by specifying the XQuery equivalents of the 
  supported queries

  
 

  
5) Allow for 
  extensibility

  
Actually this comes for free with the Web Services 
  type approach. A service can always provide an enhanced query interface - e.g. 
  full XQuery.

  
 

  
 

  
Of these principles, the one that has the most impact 
  is 3 since it encourages a minimalist 'slot filling' type query approach. In 
  each case a SAML. One of the notable features of the SAML application is that 
  in each case the query is directed at a specific subject. This coupled with 
  the separate toplevel types criteria suggests the following 
  structure:

  
 

  
SAMLQuery  [Abstract]

  
    -> SAMLSubjectQuery 
  [Abstract]

  
        
  -> SAMLAuthenticationQuery

  
        
  -> SAMLAuthorizationQuery

  
        
  -> SAMLAttributeQuery

  
  [ -> SAMLXQuery ]   (when 
  XQuery is specified)

  
 

  
The two abstract types could be compounded into one, 
  however this would allow for less extensibility, an XQuery interface would 
  logically plug into the SAMLQuery slot. Equally, XACML policy queries would 
  likely have a resource as the base rather than a subject.

  
 

  
The SAMLAuthenticationQuery does not appear to 
  require additional data.

  
 

  
The SAMLAuthorizationQuery requires the resource for 
  which the authorization is requested to be specified.

  
 

  
The SAMLAttributeQuery requires some means of 
  identifying the specific attributes that are of interest. The subject provides 
  part of the scope for the query since the issuer should only be returning 
  attributes that relate to that issuer. The requestor could specify the 
  specific attributes that are of interest, potentially the resource to which 
  access is requested might direct the query.

  
 

  
I suspect that the AttributeQuery will require some 
  degree of wildcarding. Consider the case in which we are asking for the 
  subject credit limit. Do we have to make individual queries for credit limits 
  for $50, $100, ... etc. Clearly some form of wildcarding is inevitable and 
  will occur whether it is explicitly supported by the spec or users develop 
  their own conventions.

  
 

  
I will sketch out some XMLSchema to support this and 
  issue a core09 draft by COB today.

  
 

  
        
  Phill

  
 

  
Phillip Hallam-Baker FBCS 
  C.Eng.
Principal Scientist
VeriSign Inc.

781 
  245 6996 x227

Phillip Hallam-Baker (E-mail).vcf
← Prev in month ← Prev in thread
Next in thread → Next in month →