[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Actions from the Focus Group meeting
At F2F #2, I spoke in favor of "strong typing" in the XML. It's generally
considered better design to do early signaling of the type of element
you're in, that is, using a unique name for the parent element rather than
relying on interpretation of the content. This way, streaming applications
can get started doing something as soon as they hit the outer
element. (Don't forget that attributes on the outer element might also
need type-specific interpretation, so they're helped by this too.)
If we think we'll have multiple assertions per SAML message, that's fine,
and certainly XML can accommodate such a structure. Nesting of assertions
can even be done. But having unique element names is usually a nice, clean
way of distinguishing all the types of things, and we can still declare
them as specializations of a single XML Schema complex type to make it
easier for processors to handle the common parts in a unified fashion.
BTW, at the last F2F Phill mentioned the similarity of the
Subject-Action-Object structure to RDF assertions. (See
http://www.w3.org/2001/sw/ for more information about RDF and the Semantic
Web.) I do think that more specific names would probably be a good thing,
but I'm also tending to think that we should make SAML assertions be
RDF-compatible if possible. I'm given to understand that we could do this
in an unobtrusive way, and it would open up the ability to use
already-available RDF tools to manipulate our assertions. Is anyone on the
list familiar enough with RDF to comment?
Eve
At 10:29 AM 5/4/01 -0700, Philip Hallam-Baker wrote:
>>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
--
Eve Maler +1 781 442 3190
Sun Microsystems XML Technology Development eve.maler @ east.sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC