RE: Actions from the Focus Group meeting

[Philip Hallam-Baker <pbaker@verisign.com>]

Title: FW: Actions from the Focus Group meeting

Issues 1

Should assertions be "strongly typed".  One camp feels that assertions should indicate their type within the SAML taxonomy of assertion types (authentication, attribute, decision).  Another camp feels that the contents of the assertion are sufficient to deduce their type and that explicitly including the type is redundant.

I think those who argue "against" strong typing would say that the general assertion structure may find application in unexpected places and it is unnecessarily restrictive to name them within the SAML taxonomy.

I think those who argue "for" strong typing would say that we have to find the simplest solution to the use cases.  We don't have to solve any problems beyond those.  Having assertions declare their type will facilitate their processing, because it removes any potential ambiguity about the meaning of their contents.

Phill, I think you are an opponent of strong typing.  So, why don't you lay out your arguments in response to this email? 

I think my issue is slightly different, I think we all agree on the following principles:

1) When an assertion issuer recieves a request there should be a direct correspondence between the request and the response.

2) The party making the response should be able to directly apply the response to the application

The issue is wether the 'strong typing' should be imperative or declarative in nature.

Imperative strong typing implies that we construct an FSM and specify the types of the messages that cause transitions between particular states.

Declarative typing implies that we distinguish between messages on the basis of the information they carry. So we distinguish between an attribute assertion and an authorization assertion.

The key point of difference is I believe that in the types of scenarios I work with I may ask questions that do not fit into the neatly delineated boxes. I may make a single request for both attributes and authorizations in the same bundle and in fact the distinction between them may not be very sharp.

What this comes down to is nesting. I don't like the idea of having three separate toplevel elements that all have the same internal structure, with the sole exception of different object specifiers.

Instead I would like to differentiate the assertion types at the point in the XML tree where the distinction occurs.

So for example we have a SAML authorization system which involves the following data:

Site 1 [site1.example]

Roles:            Finance Auditor Administrator ...
Attributes:        Engineer Scientist Director VicePresident ...
Resources:        accounts.xls patent1.doc takeover.doc

The application also involves site 2 and so we use URL and/or URN naming prefixes to disambiguate:

URN:dnsdate:site1.example:20010503:Finance
URN:dnsdate:site1.example:20010503:Auditor
URN:dnsdate:site1.example:20010503:Administrator

URN:dnsdate:site1.example:20010503:Engineer
URN:dnsdate:site1.example:20010503:Scientist
URN:dnsdate:site1.example:20010503:Director

file://fileserve.site1.example/accounts.xls
file://fileserve.site1.example/patent1.doc
file://fileserve.site1.example/takeover.doc

So the question becomes does it make sense to differentiate in the protocol between a URI representing a role, an attribute, a resource? I think so: 

<Assertion>
   <AssertionID>
   <Issuer>
   <ValidityInterval>
   <Claims>
      <Binding>
         <Subject>
         <Object>
            <Role>*
            <Attribute>*
            <Resource>*
               <ID>
               <Action>

Note that the Action (verb) binds to a role since the only possible action for role is by definition "has a" and the only possible action for attribute is by definition "is a".

Now we could rename Action "Verb" and end up with an XML encoding for RDF however I think that would be more for the sake of symmetry than functionality.

So Tim, are object definitions of this type sufficiently strongly typed for you?

The last remaining question is how you ask for the data in a request. I think that the <Respond> element will serve very well here:

Give me the roles: <Respond><string>Role</string></Respond>
Give me the attributes: <Respond><string>Attribute</string></Respond>
Give me the resources: <Respond><string>Resource</string></Respond>

Give me roles and attributes <Respond><string>Role</string><string>Attribute</string></Respond>

In discussion with Marlena we sorta got towards the concept of a request as being 'give me the following pieces of data that relate to this context' where the context contains at a minimum a principal but may also include specific attributes, specific roles and quite possibly a resource.

This then raises an interesting question. In the single platform O/S security model we essentially ask for 'all the groups Alice is a member of'. In the cross domain case we may well end up asking for a restricted subset. This then affects cacheability. The key issue being non-membership cannot be infered from omission. This has a major impact on Deny actions....

We could add in <NotAttribute> and <NotRole> elements.

        Phill

Phillip Hallam-Baker (E-mail).vcf