[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