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

["Eve L. Maler" <eve.maler@sun.com>]

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