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: Re: [security-services] Fragment identifiers (again)


I'm wavering on whether I like this or not.  If it can be mapped cleanly to 
official URI reference and base URI semantics, then I think it's an 
acceptable way to shorten these attribute values, but I don't place a 
particularly high value on shortening them.

The clean mapping part concerns me a little bit.  My understanding of base 
URIs is imperfect, but I believe it is legitimate to set a base URI as part 
of the context of the "SAML application" (see RFC 2396 and the XML Base 
spec, http://www.w3.org/TR/xmlbase/).  The base URI could be set to 
...draft-sstc-core-26/ only for the attributes and elements that are meant 
to contain only SAML-native URI-based identifiers.  But this is weird, 
then, if nearby there are other URI-based identifiers (e.g., for Actions or 
Attributes) that get their base URI by some other means.  If that's okay 
with everyone else, then I'm not going to go to the mat against it.

(This also raises an auxiliary question: Should SAML be 
xml:base-aware?  XML Base is a tiny spec that defines just the xml:base 
attribute.  If we want it to be respected in defining base URIs in SAML, we 
have to incorporate it explicitly in our schemas/specifications.  In fact, 
xml:base may be one way we could choose to set fixed values for the 
SAML-native base URIs.)

         Eve


At 08:18 AM 2/5/02 -0800, Hallam-Baker, Phillip wrote:
>Steve proposes to adopt the XML Signature / RDF style of using fragment
>identifiers for URI identifiers that we define in the spec.
>
>E.G.
>
>URI:
>http://www.oasis-open.org/committees/security/docs/draft-sstc-core-26/artifa
>ct
>
>becomes
>
>URI:
>http://www.oasis-open.org/committees/security/docs/draft-sstc-core-26#artifa
>ct
>
>
>and so on:
>
>http://www.oasis-open.org/committees/security/docs/draft-sstc-core-26#artifa
>ct-sha1
>http://www.oasis-open.org/committees/security/docs/draft-sstc-core-26#Holder
>-Of-Key
>
>We can then state in the spec that the base URI for derreferencing these
>URIs is
>
>http://www.oasis-open.org/committees/security/docs/draft-sstc-core-26
>
>And save ourselves a lot of typing
>
>#artifact
>#artifact-sha1
>#Holder-Of-Key
>
>Ditto for RespondWith
>
>#AuthenticationStatement
>#AuthorizationDecisionStatement
>
>etc.
>
>
>BUT NOT for audience, target, location, binding etc. where the default is
>not relevant.
>
>
>This would mean minor changes to the wording of the description of using
>URIs and the relevant parts of the spec.
>
>         Phill
>
>Phillip Hallam-Baker FBCS C.Eng.
>Principal Scientist
>VeriSign Inc.
>pbaker@verisign.com
>781 245 6996 x227
>

--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com



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


Powered by eList eXpress LLC