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

[RL 'Bob' Morgan <rlmorgan@washington.edu>]

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

... and is still happening on a daily basis, as far as I can tell.

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

I could wax long and philosophical about why naming is The Only Really
Hard Problem, but I will just say that deployments will need to establish
agreements on naming to achieve interoperability regardless of what the
SAML spec says.  But I agree we should help reduce confusion as much as we
can.

> Here's a proposal, to get the debate going.

I think that you've once again proposed at least two different things here
(you're just efficient, I know).  (1) is the establishment of a
name-syntax identifier, as you describe explicitly below.  (2) is the
removal of the current use of SecurityDomain, as Hal suggested in the
NameIdentifier thread of a couple of weeks ago:

http://lists.oasis-open.org/archives/security-services/200202/msg00128.html

  Drop security domain. In Name, specify that AP must use either the
  "normal" repesentation for that type of name (e.g. name@realm) if there
  is one or "Domain{magic SAML delimiter}Name" where {magic SAML
  delimiter} is something we agree on.

Simon's and Prateek's responses to your proposal were complaining about
(2).  I don't think we came to consensus about it in the thread from Feb
14-15.  We shouldn't mix the two proposals.

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.

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

If we do abandon SecurityDomain in its current role, then I agree that it
makes sense to tag the syntax of the now-atomic Name part.  I note that
RFC 2459 does something very similar with the GeneralName syntax that can
be used for an X.509 SubjectAltName:

      GeneralName ::= CHOICE {
           otherName                       [0]     OtherName,
           rfc822Name                      [1]     IA5String,
           dNSName                         [2]     IA5String,
           x400Address                     [3]     ORAddress,
           directoryName                   [4]     Name,
           ediPartyName                    [5]     EDIPartyName,
           uniformResourceIdentifier       [6]     IA5String,
           iPAddress                       [7]     OCTET STRING,
           registeredID                    [8]     OBJECT IDENTIFIER}

We might not need all of the above.

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

 - RL "Bob"