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

["Philpott, Robert" <rphilpott@rsasecurity.com>]

I also had the action item.  I concur that the changes are correct.

I'd recommend one minor change.  In Section 7.3, I'd list the "unspecified"
identifier first so it doesn't end up in the middle of the list if we add
more later on.  Also, it is the default value if no other format is
specified, so describing it first makes sense to me.

Rob Philpott 
RSA Security Inc. 
The Most Trusted Name in e-Security 
Tel: 781-515-7115 
Mobile: 617-510-0893 
Fax: 781-515-7020 
mailto:rphilpott@rsasecurity.com 


-----Original Message-----
From: Irving Reid [mailto:Irving.Reid@baltimore.com] 
Sent: Monday, September 30, 2002 11:23 PM
To: 'Eve L. Maler'; security-services
Subject: RE: [security-services] Concrete proposal for changes to fix the
fragment ID problem

I took an action during the conference call two weeks ago to review Eve's
proposal. I've gone through the 1.0 spec to make sure that things line up,
and that the NameIdentifier Format attribute is the only place where we
specified relative URI fragments.

I'm satisfied that this proposal is complete and correct.

 - irving -

> -----Original Message-----
> From: Eve L. Maler [mailto:eve.maler@sun.com]
> Sent: Tuesday, September 17, 2002 11:32 AM
> To: security-services
> Subject: Re: [security-services] Concrete proposal for changes to fix
> the fragment ID problem
> 
> 
> 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
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> 
> 
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> 


----------------------------------------------------------------------------
-------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the
contents of this message by a third party or as a result of any virus beingp
 assed on.
 
This footnote confirms that this email message has been swept for Content
Security threats, including
computer viruses.

http://www.baltimore.com

 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>