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

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

> A strict read, I think, implies that:
> 
> *	For each principal, an IDP must keep state about what 
> identifier, if any, it has used to represent that principal 
> to any particular SP.

Yes, but that "state" could be "all my principals are represented by X.500
DNs or email addresses and I don't care who the SP is". Which would (to my
understanding) reflect a lot of current SAML 1.1 practice.

Personally, I think it's the IdP's perspective that's relevant, not the
SP's. But to the extent that an IdP is creating identifiers/mappings on
demand (with principal consent, for example), that's what AllowCreate
applies to.

If you're not doing that, then no, I think the flag is mostly irrelevant
because identifiers aren't "created" because an SP wants them to be, they
exist independently of that. That's why it's clearer with persistent because
it's a mapping. But all identifiers are ultimately mappings. Some just have
traditional behavior outside of SAML.

The one case that's weird is transient, since that's strictly speaking
always on demand, so the flag is required to be true given that we didn't
call that case out.

> *	For a given principal and SP pair, if the IDP hasn't 
> already established an identifier to represent that principal 
> to that SP, then it cannot do so unless the AllowCreate flag 
> is set to 'true' in the <AuthnRequest>.

That's strictly true, but again, it depends on the process by which an
implementation "establishes" such an identifier.

> *	Once such an identifier is established to represent a 
> principal to an SP, the IDP must use it consistently in the 
> future (until it's changed or terminated).

Definitely not true (in core). The IdP can do whatever it wants. If I send
email address today and X.500 DN tomorrow, that's up to me. Unless the SP
specifically asks for something else (or indicates in metadata it only
supports one or the other, etc.)

Now, does that make a lot of sense? Probably not for account linking, but
that's a deployment decision.

> This would allow SPs to link accounts, or not, at their own 
> discretion but independent of the name id format used.

*That* was my original point. From the SP side, the format is entirely
irrelevant. All that matters is that the IdP be consistent, because that's a
requirement of that use case.

> AllowCreate attribute.  In the "basic use case" requirements 
> it was clearly stated that for the <NameIDPolicy> of an 
> <AuthnRequest> "an AllowCreate attribute is OPTIONAL, but if 
> sent must be set to false" and that the format value must be 
> 'X.509'.

That would certainly be a typical situation, because X.500 names are
generally *not* created on the fly.

> In the "optional use case" requirements the format 
> was required to be 'persistent' and the AllowCreate attribute 
> was required to be set to true.   Where in the basic use case 
> did the IDP "established an identifier usable by the 
> requester"?

The second the IdP was told to treat X.500 names that way.

The problem isn't so much that it's vague, it's that the number of potential
knobs is enormous because the range of use cases is. Trying to codify rules
to reduce the number of knobs is an implementation choice, but it's not one
the spec imposes.

-- Scott