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


Sorry (again) for my recent absences.  Did the group ever talk about my 
idea of adding a non-normative "SHOULD note" in 1.1 regarding using 
absolute URIs?  This could take the form of doing item "m" below in 1.1, 
except that the MUST would be a SHOULD.

	Eve

Philpott, Robert wrote:
> 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                     NEW!!! cell +1 781 354 9441
Web Technologies and Standards               eve.maler @ sun.com



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


Powered by eList eXpress LLC