[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [security-services] NameIdentifier proposed change (Sun L3 comment)
At 12:05 PM 2/14/02 -0500, Irving Reid wrote: > > From: Eve L. Maler [mailto:eve.maler@sun.com] > > > L3. Make NameIdentifier non-empty > > > > NameIdentifier and its type (Section 2.4.2.2) add up to an empty > > element. Given our distaste for attributes in general, it seems > > better for NameIdentifier to use element content for its "main" > > purpose (e.g., what's currently in its Name attribute). > > > > Here's the way it would look in the instance: > > > > <NameIdentifier > > SecurityDomain="example.com">joeuser</NameIdentifier> > > > > Here is the proposed change to the schema: > > > > <complexType name="NameIdentifierType"> > > <simpleContent> > > <extension base="string"> > > <attribute name="SecurityDomain" type="string"/> > > </extension> > > </simpleContent> > > </complexType> > > >I like this change, but there's one thing that I think needs discussion. >Currently, the SecurityDomain attribute is optional. Yep, we have that problem already whether we change the structure of NameIdentifier or not. >I see two >possibilities: > >(1) Change it to <attribute name="SecurityDomain" type="string" >use="required"/> > >(2) Explicitly describe how relying parties are expected to interpret a >missing SecurityDomain. > >I'm a little bit inclined toward (2), but I'm not sure we could come up with >an interpretation that satisfies everyone. > >The simplest approach would be to say that if SecurityDomain is not >specified, RPs should interpret as SecurityDomain == Issuer. 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? >Another approach would be to say that RPs should base their policy on the >Issuer, and just use SecurityDomain to further qualify names. However, that >makes it difficult to do multiple Issuers producing assertions about >overlapping sets of SecurityDomains (i.e. RP trusts Issuer1 to assert about >Domain1 and SharedDomain, and trusts Issuer2 to assert about Domain2 and >SharedDomain) > >Can anyone think of another alternative, or have an opinion about which of >these are preferred? Eve -- Eve Maler +1 781 442 3190 Sun Microsystems XML Technology Center eve.maler @ sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC