RE: [security-services] ISSUE: NameIdentifier specification needs tobe clarified

["Mishra, Prateek" <pmishra@netegrity.com>]

>>
>>So I think the question has to be put regarding (2):  do we need
>>SecurityDomain as it has been used up to now, ie as a 
>>separate location to
>>hold the administrative domain in which the name exists, eg 
>>washington.edu
>>or "o=baltimore inc, c=ca"?  My opinion (today):  we do not 
>>(and yes, I
>>probably did argue for it way back when), so we should remove 
>>it and have
>>Name be a single element.


IMHO, this is a serious misunderstanding of the role of security domain.
It makes absolutely no sense to take a name in a standard syntax (X.509 DN)
and split it up into its component pieces.

Instead, security domain provides a way to aggregrate a number of distinct
user stores "behind" a single issuer. In the deployments I work with we
often have the following situation:

(1) Company Employees are held in a SQL - database and their name is an
employee id (shouldn't be the social security number but it often is).

(2) Company customers are held in an LDAP database with proper LDAP DN's.

In this case, we would have two security domains:

<SecurityDomain>Employee<SecurityDomain>  with <Name>databaseKey</Name>

<SecurityDomain>Customer</SecurityDomain> with <Name>X.509 DN</Name>




>>
>>It seems to me there are two forms of subject identifiers in 
>>widespread
>>use:  email/Kerberos (user@domain) and X.500 DN.  The 
>>email/Kerberos form
>>is already well-delimited by the "@" character; splitting 
>>this form into
>>pieces for XML representation doesn't seem to buy much.  The 
>>DN form is
>>a sequence of RDNs (AVAs) which it doesn't make sense to 
>>split arbitrarily
>>into two parts.  UUIDs might also be used, and they can't be 
>>split at all.

You have described an ideal world here. In practice, there are
great many namespaces, some with peculiar properties. The <SecurityDomain>
element provides an "ad-hoc" means to federate these identities.



>>So the idea of a SecurityDomain being an inherent part of a 
>>subject name
>>doesn't seem to go very far.  In Shib we've spent a lot of 
>>time worrying
>>about how and whether to do the split (with Kerb-style SNs) 
>>and I'm sure
>>others would do the same.
>>
>>The only strong argument for it, I think, is that separating Name from
>>SecurityDomain permits Name to be encrypted using XML 
>>Encryption, while
>>SecurityDomain remains in the clear.  This doesn't seem very 
>>compelling to
>>me.
>>

My comments above should make it clear that I disagree with this
position.


- prateek