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

["Brian Campbell" <bcampbell@pingidentity.com>]

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

I would argue that would not be sufficient to satisfy the wording in the
spec.  That, regardless of the format, the IDP must keep track of what
principals it has issued identifiers for and to which SPs - without that
it cannot honor the processing rules around AllowCreate.  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.

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

Why make that distinction?  And even if that is the proper distinction
to make, it is not at all clear to me from reading the specs.

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

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.

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

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.

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

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?  

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

They aren't created on the fly (IMHO) what is created is the association
of the use of that name with a particular SP.  If all IDPs are
consistent about this, then SPs can treat AllowCreate consistently
without knowledge of the IDPs deployment and are free to link or not
link as they choose.

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

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

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

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.

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