Re: [security-services] Issuer / NameIdentifier overlap

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

Since XACML has essentially asked for Issuer expressiveness as good as 
SAML's current NameIdentifier, and since we're contemplating adding to 
the expressiveness of the latter, I think it's better to unify them to 
avoid hassles later.  This is aside from the larger "argument from 
processing elegance", though that has appeal too.  So option (b) sounds 
best to me.

	Eve

Scott Cantor wrote:

> I guess a few of us were nominally supposed to submit use cases around
> assertions about issuers of assertions, so I guess this is a start for that,
> but mostly just want to bring a few points to bear.
> 
> The one use case that was mentioned was from Tony, with the idea of
> expressing operational/policy metadata as an assertion (perhaps in one or
> more attributes). Which I think is interesting, but I'd note that that
> doesn't actually require that Assertion Issuer be something like
> Subject/NameIdentifier. It's just being able to reference somebody that
> might be an Issuer *in* a Subject/NameIdentifier.
> 
> Another use for that I can imagine is some kind of trust brokering assertion
> that lets me rely on a SAML authority to justify a decision to rely on a
> different SAML authority.
> 
> So it's fair to say this is reasonable, and in fact my latest drafts around
> new NameIdentifier usage proposes a NameIdentifier Format URI for
> representing the identifier of a "provider", which is in some cases
> something that could issue assertions itself. We might want to change the
> name, but the basic idea is sound.
> 
> But do we have use cases in which a Subject/NameIdentifier would issue
> assertions about something? Sure, anything could be a SAML authority by
> definition, since it's a definition based on what you do, not who you are.
> But couldn't I simply have an identifier that applies to me as an assertion
> Issuer distinct from my various NameIdentifiers? I don't see why not.
> 
> So I think the question is whether there is just an intrinsic advantage in
> unifying the way we refer to entities in the domain model. I think the
> answer might be yes, but maybe not if we just decide to stay with the
> current model of a simple string.
> 
> If we just stick with Issuer as a string attribute, and don't go any
> further, than there's some advantage to that simplicity, I think. I'd even
> favor going farther and forcing that be a URI, for uniqueness and to
> reinforce the purpose, which is really to provide a hook into the metadata.
> In 1.x we didn't have metadata, and I would argue that Issuer was useless as
> a result (except if you then added custom metadata, such as Shibboleth
> did/does).
> 
> XACML proposes we add an IssuerFormat attribute, to profile the use of the
> string value. I would argue we probably don't want to complicate the
> situation without a commensurate return on that investment. In my mind,
> there are two options:
> 
> a) Keep a single Issuer attribute, intended only as a way of referencing
> whatever other information is available in metadata or elsewhere, so it
> doesn't matter what the format is.
> 
> b) Create a consistent way of referencing "entities" be they people or
> authorities, and replace the existing Issuer attribute with a
> <NameIdentifier> element in <Request>, <Response>, and <Assertion>.
> 
> At least with (b), I get code and expression reuse. Going halfway and ending
> up with two distinct non-trivial methods seems like a bad idea.
> 
> -- Scott
-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  NOTICE: This email message is for the sole use of the intended
     recipient(s) and may contain confidential and privileged
     information. Any unauthorized review, use, disclosure or
     distribution is prohibited. If you are not the intended
     recipient, please contact the sender by reply email and
           destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~