RE: [saml-dev] "previously established an identifier usable by the requester"?

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

> I would argue that would not be sufficient to satisfy the wording in the
> spec.

I don't know what to say to that other than I guess I disagree. If the spec
is reading too strictly, I guess we need to discuss it on a call and perhaps
create an erratum. It's a fairly metaphysical issue, which is why it's hard
for me to see how a strict reading could ever work.

> Granted an IDP
> can say "all my principals are represented by X.500 DNs or email
> addresses and I don't care who the SP is" but it must still keep state
> about if it has previously issued an assertion to each SP for each
> principal. Otherwise it can have no way of knowing if it has "previously
> established an identifier usable by the requester" - which is 
> a MUST in the specification.

I disagree. If everybody gets the same one, then by definition, there's one
established (for any SP). Maybe that's too tricky, but I wasn't trying to
back-door anything.

> Ok, but what I'm hearing is that an SP must have deployment specific
> knowledge of the way that the IDP treats identifiers in order to
> determine how to treat certain protocol rules.

You can choose whether to send true or false, but what's deployment specific
is whether it makes any sense or not. For some deployments, I would expect
it to be hardwired to true. For others, the setting represents some kind of
consent operation such that if the IdP has to actually create an explicit
link, that operation can be tracked. If the types of identifiers and the way
they're used is such that it's irrelevant, than it works either way.

> > Now, does that make a lot of sense? Probably not for account linking,
> > but that's a deployment decision.
> 
> Who's deployment decision?  The linking decision should be the SPs
> decision, and only the SPs.  And the SP should be able to do either
> regardless of the IDP its working with.

Try account linking with an IdP that only gives you transient handles and
never gives you a persistent attribute. It is very much a mutual decision to
support this use case with a given pair of providers.

There are obviously deployment modes at both ends that are mutually
exclusive.

> But you've said above that the IDP doesn't need to be consistent - "The
> IdP can do whatever it wants. If I send email address today and X.500 DN
> tomorrow, that's up to me."  So what is an SP suppose to do?  

Be prepared for the fact that a misconfigured IdP might be doing things that
are going to be a problem for it. In this particular case, you'd have no way
of even knowing, frankly. This is why we specifically made "persistent" a
separate format. It's the only one that provides processing rules that
specifically address that use case. That doesn't mean the others don't work,
but they leave more holes that an IdP could crawl through if people are
making odd deployment decisions.

> They aren't created on the fly (IMHO) what is created is the association
> of the use of that name with a particular SP.

There is nothing in the spec that implies to me that any kind of identifier
has to be made "particular" to an SP except for persistent (and I guess
transient). Now, could you make another format behave that way? Sure, but
you certainly don't have to.

I don't personally think that means that AllowCreate is somehow impossible
to use with anything but persistent, but I admit it's probably rare. The
alternatives weren't attractive unless we had a completely separate protocol
for dealing with one kind of name, and I thought that was a bad idea.

> Shouldn't the goal of a protocol specification like this be 
> to eliminate the need for out of band agreements?

I don't see how to eliminate them with a protocol unless the protocol
negotiates every possible decision point. And we're certainly nowhere close
to that here.

> I agree that there are a huge number of use cases here and I see where
> you are coming from (I think).  What I'm driving at is that there
> appears to be wording in the spec that only applies to some of the use
> cases.  But it's never called out - it's just assumed that it's
> understood.  It seems to me that there is a real potential here for
> interoperability problems based on varied interpretations.

I don't think there are any MUSTs in the spec that are overly specific
(except maybe in the format definitions), at least not once the qualifiers
in the text are factored into it. Now, you could argue that the qualifier
dwarfs the MUST to such an extent that the MUST is worthless. And in the
case of AllowCreate, I'd probably be inclined to agree with you.

If it helps, the point of the flag, as I understand it, is to distinguish
"authentication" from some kind of "provisioning" step. Up until now, the
concept simply wasn't called out, so there was no distinction. And for a lot
of deployments, I don't think it's a relevant one.

> Furthermore, how can NIM possibly work if the IDP doesn't track state
> the way I've described? 

I assume you mean an SP notifying an IdP to "terminate" the name? An IdP
only has to do something there if it cares. If the identifier is common to
every SP, than an SP can terminate whatever it likes to no particular
effect. And of course such a deployment just isn't very likely to be using
NIM.

Quoting myself, "If the <Terminate> element is included in the request, the
requesting provider is indicating that (in the case of a service provider)
it will no longer accept assertions from the identity provider...". In other
words, termination from an SP doesn't tell the IdP to do anything in
particular. It may do something if it makes sense to, but that's up to it.

Maybe this is a helpful way of thinking about it. I'll grant you that some
of the rules get interpreted in the context of how an implementation
supports particular formats. This is exactly what was intended. If the
format doesn't specify particular behaviors, then indeed you can't rely on
the IdP doing certain things behind the scenes.

-- Scott