OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


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

Having not heard the justification for this, I'm not sure I'd agree that
it's most natural that way. To me, consistency is the goal if you want
to encode different systems' notions of what a name and a security
domain is into one schema.

Actually, I'd say LDAP is much more problematic, because at least with
Kerberos, it's fairly apparent how to divide principal@realm into two
attributes. I don't know how you divide a DN, though I guess everything
but the first RDN component could go in SecurityDomain.

>I disagree about using the Issuer as the default Domain.

I do too.

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

This is, by another name, the scope issue we're facing in Shibboleth,
and that's also our solution. The SecurityDomain is the default, with
the attributes allowed to override it using an attribute that we define
in the attribute schema(s).
 
-- Scott



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC