Re: [security-services] Concrete proposal for changes to fix thefragment ID problem

["Eve L. Maler" <eve.maler@sun.com>]

One additional thought on this proposal: The item #n I propose below 
(tell people to use absolute URIs) should perhaps also be added to the 
core spec as a strong SHOULD in 1.1.  This isn't backwards incompatible, 
and will serve as a useful heads-up indication of what will change in 2.0.

	Eve

Eve L. Maler wrote:
> For reference, my original proposal on this subject can be found at:
> 
> http://lists.oasis-open.org/archives/security-services/200206/msg00036.html
> 
> The main difference between what I'm proposing now and what I proposed 
> in June is that we need to do things in a slightly different order and 
> manner, now that we know the "erratum" path is closed to us.  Here are 
> the changes needed (referring to line numbers in cs-sstc-core-01, and 
> assuming that the version in which this will happen is "1.1"):
> 
> ========
> 1. In Section 2.4.2.2, change lines 598-615 to read as follows:
> 
>   "A URI reference representing the format in which the <NameIdentifier> 
> information is provided. See Section 7.3 for some URI references that 
> MAY be used as the value of the Format attribute.  If no value is 
> provided, the identifier 
> urn:oasis:names:tc:SAML:1.0:nameid-format:unspecified (see Section 
> 7.3.4) is in effect. Regardless of format, issues of anonymity, 
> pseudonymity, and the persistence of the identifier with respect to the 
> asserting and relying parties, are also implementation-specific."
> 
> ========
> 2. Remove lines 627-628 (they will be effectively moved to Section 7, as 
> you'll see below) and lines 629-630 (they have been moved up, as you can 
> see above).
> 
> ========
> 3. Add a new Section 7.3 after line 1619:
> 
> 7.3 NameIdentifier Format Identifiers
> 
> The following identifiers MAY be used in the Format attribute of the 
> <NameIdentifier> element (see Section 2.4.2.2) to refer to common 
> formats for the content of the <NameIdentifier> element.  The 
> recommended identifiers shown below SHOULD be used in preference to the 
> deprecated identifiers, which will be removed in the next major version 
> of the SAML assertion specification.
> 
> 7.3.1 Email Address
> 
> Recommended URI: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
> Deprecated URI: urn:oasis:names:tc:SAML:1.0:assertion#emailAddress
> 
> Indicates that the content of the <NameIdentifier> element is in the 
> form of an email address, specifically "addr-spec" as defined in IETF 
> RFC 2822 [RFC 2822] §3.4.1. An addr-spec has the form local-part@domain. 
> Note that an addr-spec has no phrase (such as a common name) before it, 
> has no comment (text surrounded in parentheses) after it, and is not 
> surrounded by "<" and ">".
> 
> 7.3.2 X.509 Subject Name
> 
> Recommended URI: urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName
> Deprecated URI: urn:oasis:names:tc:SAML:1.0:assertion#X509SubjectName
> 
> Indicates that the content of the <NameIdentifier> element is in the 
> form specified for the contents of the <ds:X509SubjectName> element in 
> the XML Signature Recommendation [XMLSig]. Implementors should note that 
> the XML Signature specification specifies encoding rules for X.509 
> subject names that differ from the rules given in IETF RFC 2253 [RFC 2253].
> 
> 7.3.3 Windows Domain Qualified Name
> 
> Recommended URI: 
> urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName
> Deprecated URI: 
> urn:oasis:names:tc:SAML:1.0:assertion#WindowsDomainQualifiedName
> 
> Indicates that the content of the <NameIdentifier> element is a Windows 
> domain qualified name. A Windows domain qualified user name is a string 
> of the form "DomainName\UserName". The domain name and "\" separator may 
> be omitted.
> 
> 7.3.4 Unspecified
> 
> URI: urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
> 
> The interpretation of the content of the <NameQualifier> element is left 
> to individual implementations.
> 
> ========
> m. In the next major revision, SAML 2.0, change the SAML Core document 
> as follows: To the final sentence of Section 1.2.1 beginning on line 
> 203, add ", and must be absolute [RFC 2396]."  The reason this cannot be 
> added to a minor revision is that it restricts the possible values of 
> SAML URIs, and is thus backwards incompatible.
> 
> ========
> n. In the meantime, any interoperability document we publish must stress 
> that it is expected current practice to use only absolute URI 
> references, as shown in the deprecated URIs above.
> 

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 883 5917
XML Web Services / Industry Initiatives      eve.maler @ sun.com