[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