OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: 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.

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
781 245 6996 x227

-----Original Message-----
From: Phillip Hallam-Baker [mailto:pbaker@verisign.com]
Sent: Wednesday, June 20, 2001 11:47 AM
To: 'security-services@lists.oasis-open.org'
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.
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.
Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
781 245 6996 x227

Phillip Hallam-Baker (E-mail).vcf

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC