RE: [security-services] ISSUE: Fragment identifiers for URI references on the Format attribute

["Mishra, Prateek" <pmishra@netegrity.com>]

Eve,

looking through our code, I find that  
all we do is treat the fragment identifiers as strings:
#emailAddress etc.

Is this bad? I guess the problem is that they may also
validly be complete URLs.

- prateek

>>-----Original Message-----
>>From: Eve L. Maler [mailto:eve.maler@sun.com]
>>Sent: Tuesday, June 25, 2002 11:55 AM
>>To: Eve L. Maler
>>Cc: 'security-services@lists.oasis-open.org'
>>Subject: Re: [security-services] ISSUE: Fragment identifiers for URI
>>references on the Format attribute
>>
>>
>>I have finally had a chance to consult with Paul Grosso, chair of the 
>>W3C XML Core WG and an expert on the subtleties of base URIs. 
>> I believe 
>>that we do need to make a change, and that we need to discuss 
>>this topic 
>>in today's call.
>>
>>By the way, I never did hear back from any developers on what their 
>>Format values are looking like.  Can people weigh in on this?
>>
>>Briefly:
>>
>>- URNs can have fragment identifiers, so it's not strictly 
>>wrong for us 
>>to give fragment IDs to them.  However, no one ever really 
>>uses them, so 
>>implementation experience is sparse.
>>
>>- I was wrong about application-dependent base URIs being a solution. 
>>They are the last in a chain of base URI building, and 
>>typically they're 
>>never reached because something else (e.g., the location of a file) 
>>takes precedence.
>>
>>- In any case, if anyone does use just a fragment ID and not 
>>a whole URI 
>>reference for the Format attribute, the correct 
>>interpretation is *not* 
>>to add a "base URI" coming from some unknown source; empty 
>>URI portions 
>>always refer to the *current document* and never to a base.  
>>(Base URIs 
>>are *incomplete* URIs that must be completed by the addition of a 
>>relative URI.)
>>
>>- In talking about URI-based identifiers, we gloss over some 
>>important 
>>distinctions.  Because we don't restrict these to *absolute* URI 
>>references (as the XML Namespaces spec does), we're caught 
>>not knowing 
>>how to apply different stages of normalization and 
>>absolutization that 
>>URIs usually go through.
>>
>>- If we were to insist that URI-based identifiers always be 
>>absolute, we 
>>solve most potential interoperability problems.
>>
>>- If we later get rid of our own fragment IDs for Format 
>>attributes, we 
>>take away some confusion.
>>
>>My recommendations:
>>
>>1. That we add, somewhere in a cs-sstc-core-02 if possible, the 
>>statement that URI-based identifiers are REQUIRED to be 
>>absolute in form.
>>
>>2. That if the next version of SAML is an increment to the 
>>minor version 
>>number, we add an alternate set of URNs corresponding to the 
>>Format choices.
>>
>>3. That in the next version of SAML that increments the major version 
>>number, we replace the old fragment ID-based Format values with the 
>>URN-based values.
>>
>>I'm not sure of our leeway to make changes such as #1 above 
>>at this late 
>>date, but if we don't make this change, there's definitely an erratum 
>>lurking in our future on this.
>>
>>	Eve
>>
>>Eve L. Maler wrote:
>>> The following is a relatively minor set of potential issues 
>>on SAML 1.0 
>>> Committee Spec-01.  Note that we're going to need a process for 
>>> collecting issues going forward, or at least we need to 
>>continue our 
>>> existing process...
>>> 
>>>             *        *        *
>>> 
>>> In cs-sstc-core-01, lines 599-615 contain the only use of fragment 
>>> identifiers in the whole spec anymore: they describe the 
>>values for the 
>>> Format attribute, such as #emailAddress, on <NameIdentifier> .  I'm 
>>> wondering why we didn't make these whole URNs, as we 
>>ultimately did for 
>>> everything else.  Also, here we refer a bit obliquely to base URIs: 
>>> "assuming a base URI of the SAML assertion namespace name" 
>>(lines 600-601).
>>> 
>>> I have the following concerns:
>>> 
>>> - Did we mean that it should be possible to set an explicit 
>>base URI 
>>> somewhere and then in the Format attribute use only the 
>>fragment ID?  If 
>>> so, were we assuming that the base URI would be set using 
>>the XML Base 
>>> spec?  If we were relying on XML Base, we would have to 
>>make explicit 
>>> reference to it in the text; you don't get XML Base free by 
>>using XML 
>>> (yet).
>>> 
>>> - Alternatively, did we mean that SAML has its own 
>>application-specific 
>>> semantics about the base URI?  This may be perfectly acceptable 
>>> ("application-dependent semantics" as defined in RFC 2396); 
>>I just think 
>>> our text isn't quite clear enough in this case.
>>> 
>>> - The semantics for base URIs are really tricky; I'm not an 
>>expert, but 
>>> I'm concerned we may be breaking the semantics for "empty" 
>>URIs (such as 
>>> the empty URI string a Format attribute value of 
>>"#emailAddress") if we 
>>> do assume that the base URI is set elsewhere and can be 
>>implicit on the 
>>> Format attribute.
>>> 
>>> The good news, if there are issues here, is that the 
>>workaround is to 
>>> always supply the whole URN+fragID.  (What is current practice by 
>>> implementors?)
>>> 
>>> Assuming that my fears about "empty" URIs are unfounded (I 
>>will check 
>>> with a base-URI expert of my acquaintance), an easy 
>>fix/enhancement in 
>>> the direction of application-specific base URIs would be to 
>>clarify the 
>>> "assuming a base URI of the SAML assertion namespace name" 
>>wording. This 
>>> is perhaps a minor enough clarification that there may be a 
>>way to do it 
>>> for the OASIS Standard level, if we get that far...
>>> 
>>> If we want to allow the use of XML Base (that is, the xml:base 
>>> attribute), the change would be quite a bit more invasive.  
>>We'd want to 
>>> explicitly allow for the attribute in our schemas, and make 
>>normative 
>>> reference to the XML Base spec from our core spec.  I 
>>wouldn't want to 
>>> go here for a while.
>>> 
>>>     Eve
>>
>>
>>-- 
>>Eve Maler                                        +1 781 442 3190
>>Sun Microsystems                            cell +1 781 883 5917
>>XML Web Services / Industry Initiatives      eve.maler @ sun.com
>>
>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>