With attachment! RE: Core 09 RE: Action Items.

Title: RE: Contradictory requirements?

duh!

 

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

781 245 6996 
x227

  
-----Original Message-----
From: Phillip Hallam-Baker 
  
Sent: Wednesday, June 20, 2001 1:56 PM
To: Phillip 
  Hallam-Baker; ''
Subject: Core 
  09 RE: Action Items.

  
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

draft-sstc-core-09.doc