RE: [security-services] NameIdentifier proposed change (Sun L3 comment)

[Hal Lockhart <hal.lockhart@entegrity.com>]

Title: RE: [security-services] NameIdentifier proposed change (Sun L3 co mment)

> > I thought someone had pointed out a case where the name
> > string has the
> > security domain baked in (I can't remember the example).  In
> > this case, it
> > would perhaps be silly or error-prone to repeat the security domain
> > information in a separate attribute, and the correct
> > interpretation would
> > be "Get the security domain info from the Name field".  Would
> > the security
> > domain always == the Issuer in such cases?
>
> A common example of where the name implies the SecurityDomain
> is in LDAP
> Distinguished Names, such as "cn=Irving Reid, ou=Engineering,
> o=Baltimore.com". In this case, the RP still needs some sort
> of policy that
> says whether Issuer "malicious.com" is allowed to assert
> things about that
> DN.

An even more important example is name@realm as in Kerberos or Internet email addresses.

The history of this is that Stephen Farrell suggested that Domain be a separate element so it could be encrypted or not independantly from name.

Some time later, Stephen Farrell asked that Domain be optional because in may cases, such as Kerberos, it was most natural to make the domain part of the name.

I disagree about using the Issuer as the default Domain.

I would also like to point out that Attributes have no distinct domain element. If none is specified, the subject domain will be used.

I see no good way out of this. The two choices I consider feasible are:

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

2. Specify that AP must use either the "normal" repesentation for that type of name (e.g. name@realm) if there is one and not use SecurityDomain or put the domain in the domain in the name in the name.

In either case we could list the common cases where there is a "normal" representation.

Hal