[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [security-services] ISSUE: NameIdentifier specification needs tobeclarified
Irving, SecurityDomain in your proposal is syntactic class for the Name. I was thinking about SecurityDomain as the value defining security scope of the name, eg for irving@baltimore.com SecurityDomain=baltimore.com and Name=irving@baltimore.com or SecurityDomain could have a different value. There could be additional attribute of the NameIdentifier, eg <NameSyntax> with the value of http://www.oasis-open.org/committees/security/docs/draft-sstc-core-27#email to qualify name syntax as email address. (Also, in my copy of core 27 schema Name is an attribute. (Has it been changed to element?)) Simon ----- Original Message ----- From: "Irving Reid" <Irving.Reid@baltimore.com> To: <security-services@lists.oasis-open.org> Sent: Monday, February 25, 2002 6:12 AM Subject: [security-services] ISSUE: NameIdentifier specification needs to beclarified > I'd like to formally raise an issue that we need to clarify the semantics of > NameIdentifiers (core-27 section 2.4.2.2, lines 631ff. There has been some > discussion on the list, starting with message "RE: [security-services] > NameIdentifier proposed change (Sun L3 comment)" > (http://lists.oasis-open.org/archives/security-services/200202/msg00123.html > ) > > As I see it, the current definition of NameIdentifier is generic enough that > we could easily end up with conflicting "profiles", as happened in the early > days of X509 certificates. How do we represent an X500 DNAME? what about > email addresses? In the absence of specific guidelines, I'm afraid we'll end > up with the usual mess of standards-compliant software that doesn't > interoperate. > > Here's a proposal, to get the debate going. > > The SecurityDomain attribute on NameIdentifier is changed to an anyURI. SAML > defines specific URI values, within the SAML URI namespace, to identify > certain well known identifier formats such as X500 DNAME and Internet email > address. In these cases, the content of the Name portion is the entire > identifier. For example (using Eve's proposed non-empty element format): > > <NameIdentifier > SecurityDomain="http://www.oasis-open.org/committees/security/docs/draft-sst > c-core-27#email">irving@baltimore.com</NameIdentifier> > > <NameIdentifier > SecurityDomain="http://www.oasis-open.org/committees/security/docs/draft-sst > c-core-27#X500-dname">cn=Irving > Reid,ou=Engineering,o=baltimore.com</NameIdentifier> > > SAML applications SHOULD use defined SecurityDomain values and name formats > whenever possible. > > > If anyone else thinks this is a good idea, we can work up the normative > language. > > - irving - > > > > -------------------------------------------------------------------------- --------------------------------------- > 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 > unauthorized 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 being > passed on. > > > 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> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC