[security-services] ISSUE: NameIdentifier specification needs to beclarified

[Irving Reid <Irving.Reid@baltimore.com>]

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.