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

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

[Irving]
>>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.

First, I agree that this is a significant problem. There are several areas
in
SAML wherein provision of some set of standard syntaxes would make
significant
improvements in supporting inter-operability. These include:

<saml:NameIdentifier>

<saml:Attribute>

<saml:Actions>

(Section 7.2 lists recommends a few cases for use with SAML)

<saml:Resource>
(URI schemes are available for a number of different resource types
but none are recommended for use with SAML)

Of this list, I think <saml:NameIdentifer> and <saml:Attribute> need the
most work. The specification does not provide any guidance for these at all.


>>[Irving]
>>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):
>>

I strongly oppose this proposal. My understanding of the
current semantics of <saml:NameIdentifier> is as follows:

-------------------------------------------------------------
(1) security domain: describes the "domain" with respect to
which the subject name should be interpreted. Some examples:
name of domain controller, name of user-store, name of enterprise
from which the user originates. 

The security domain provides a context within which the <saml:Name>
component should be interpreted. It is also key to modeling federation
(identical <saml:Name> values refer to different subjects depending 
upon the security domain value)
------------------------------------------------------------------

(2) Name: provides the name of the subject. Often, this will take form
of an X.509 DN, kerberos ticket, UUID or uninterpreted binary string. This
is the
approach taken in S2ML, for example, wherein <S2ML: UserHandle> or
<S2ML:IdentityToken>
are offered as choices.

Why do we distinguish between Name and Security Domain? Mostly because
we expect Names to be drawn from a syntax with standard rules for matching
etc. It is useful to allow for an "unstructured" security domain component
and a more structured name component. 
---------------------------------------------------------------------

I oppose changing the interpretation of <saml:SecurityDomain>. I agree that
we
need to provide additional structure for the <saml:Name> element.

To conclude with a question: do we need to provide this structure in SAML
1.0? 
Can it be deferred to SAML 1.1?


- prateek