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

["Ahmed, Zahid" <zahid.ahmed@commerceone.com>]

Title: RE: [security-services] ISSUE: NameIdentifier specification needs to be clarified

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

Agreed. However, NameIdentifers is a crucial element of SAML 1.0
that we should aim to fix in SAML 1.0 in support of
interoperability. The other elements we may differ to fix
post-1.0.

>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 think we need support for a formalize definition of security
domains, both syntactically and semantically. The unstructured
definition as we have right now is loose and will break unless
2 parties do not agree how to interpret the unstructured definition
of Security Domain. I know Irving and some others have given
examples of LDAP X.500 DNs. Additionally, there may be examples in
B2B protocols where we may identify associatiation of a principal
more formally via URI domains. The option of using URIs, in addition
to the option, to extend some general, agreed-upon definition
of Securirty Domain, seems fundamental to SAML 1.0 to allow
better manage security interoperability.

See specific suggestions of required changes w.r.t. this
issue sent previously as a response to Irving's
original Issue.

thanks,
Zahid

Zahid Ahmed
Commerce Security Architect
Commerce One, Inc.
408-517-3903

-----Original Message-----
From: Mishra, Prateek [mailto:pmishra@netegrity.com]
Sent: Monday, February 25, 2002 3:00 PM
To: 'Irving Reid'; security-services@lists.oasis-open.org
Subject: RE: [security-services] ISSUE: NameIdentifier specification
needs to be clarified

[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

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>