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

[Irving Reid <Irving.Reid@baltimore.com>]

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

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?

 - irving -


-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.