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] ISSUE: Fragment identifiers for URI referenceson 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



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


Powered by eList eXpress LLC