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] Concrete proposal for changes to fix the fragmentID problem


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



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


Powered by eList eXpress LLC