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: [security-services] ISSUE: Fragment identifiers for URI references onthe Format attribute

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 

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 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