Issuer / NameIdentifier overlap

[Scott Cantor <cantor.2@osu.edu>]

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