Action Items.

Title: RE: Contradictory requirements?

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