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] 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
or SecurityDomain could have a different value.

There could be additional attribute of the NameIdentifier, eg <NameSyntax>
with the value of
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?))


----- 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

> I'd like to formally raise an issue that we need to clarify the semantics
> NameIdentifiers (core-27 section, lines 631ff. There has been some
> discussion on the list, starting with message "RE: [security-services]
> NameIdentifier proposed change (Sun L3 comment)"
> )
> As I see it, the current definition of NameIdentifier is generic enough
> we could easily end up with conflicting "profiles", as happened in the
> 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
> 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.
> defines specific URI values, within the SAML URI namespace, to identify
> certain well known identifier formats such as X500 DNAME and Internet
> 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
> c-core-27#email">irving@baltimore.com</NameIdentifier>
> <NameIdentifier
> c-core-27#X500-dname">cn=Irving
> Reid,ou=Engineering,o=baltimore.com</NameIdentifier>
> SAML applications SHOULD use defined SecurityDomain values and name
> 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
> 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
> 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