Re: [security-services] Proposed text for <NameIdentifier>

[Stephen Farrell <stephen.farrell@baltimore.ie>]

Prateek,

Looks good, some minor nits/corrections/questions below.

Stephen.

> "Mishra, Prateek" wrote:
> 
> 2.4.2.2 Element <NameIdentifier>
> 
> The <NameIdentifier> element specifies a subject by a combination of a name, a format and a
> security domain. It has the following attributes:
> 
> SecurityDomain [Optional]
>             The security domain governing the name of the subject.
> 
> Format [Optional]
>             The syntax used to describe the name of the subject.
> 
> Format values are URIs. The following standard values are defined as URI fragment
> identifiers. The base for these identifiers is the SAML assertion namespace URI.
> 
>     #rfc822Name:
>       Indicates that the value of the Name element MUST be an rfc822 name.
>       The format of an rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822].

822 was obsoleted by 2822, so 2822 is the one to use. Might also want to
s/#rfc822Name/#emailAddress/

>        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
>        ">". Note that while upper and lower case letters are allowed in an
>        RFC 822 addr-spec, no significance is attached to the case.
>     #X.500Name:
>        Indicates that the value of the Name element MUST be a X.500Name.
>        The format of an X.500Name is a "distinguishedName" as described in
>         Section 3 of RFC2253 [RFC2253]. The X.500 Directory uses
>        distinguished names as the primary keys to entries in the directory.
>         Distinguished Names are encoded in ASN.1 in the X.500 Directory protocols.
>         In the LDAP a string representation of distinguished names is transferred.
>        RFC2252 defines the string format for representing names, which is designed

Huh? Maybe "The LDAP protocol includes the definition of a string representation 
for X.500 names [RFC2252], which is designed..." The sentence was just a bit
unclear to me.

I assume "." is ok in URI local fragments? 

Also, on this one: I'm not sure if it needs to be in the spec, but the TC
at least should explore potential differences between this and the X500Name
thingy defined in dsig (a KeyInfo option), since implementations are likely
to have to support both. (I've asked one of our dsig folks.)

>         to give a clean representation of commonly used distinguished names, while
>         being able to represent any distinguished name.
> 
>     #WindowsNTQualifiedName:
>       Indicates that the value of the Name element MUST be a Windows NT qualified name.
>       A Windows NT qualified user name is a string of the form "NTDomainName\UserName".
>       The domain name and "\" separator may be omitted.
> 
> The following schema fragment defines the <NameIdentifier> element and its NameIdentifierType
> complex type:
> 
> <element name="NameIdentifier" type="saml:NameIdentifierType">
> <complexType name="NameIdentiferType">
>     <sequence>
>         <element name="Name" type="string">
>    </sequence>
>       <attribute name="SecurityDomain" type="string" use="optional">
>       <attribute name="Format" type="anyURI" use="optional">
> </complexType>

Why have the "Name" element? Is there an advantage to this as opposed to
allowing:

<NameIdentifier SecurityDomain="foo" Format="saml:#email" >
	stephen.farrell@baltimore.ie
</NameIdentifier>

I read that schema fragment as requiring:

<NameIdentifier SecurityDomain="foo" Format="saml:#email" >
	<Name>
		stephen.farrell@baltimore.ie
	</Name>
</NameIdentifier>

Which just seems to have an extra element tag for no benefit?

> The interpretation of the security domain and the name are left to individual implementations,
> including issues of anonymity, pseudonymity, and the persistence of the identifier
> with respect to the asserting and relying parties. The security domain attribute provides
> a means to federate names from disparate user stores without collision.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com