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

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

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

Ironically, Scott, it was something you said a while back that led me to
a more strict reading.  But I digress - it's certainly not my place to
tell the spec authors what their intent was :) All I can say at this
point is that my interpretation was apparently quite different from the
intent of the spec.  Maybe that means that I'm just an idiot but I
suspect that I'm not the only one with a confused or varied
interpretation.   

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

Again, who am I to disagree with the spec authors?  But my reading led
me to a different interpretation.  Perhaps it's the wrong interpretation
(wouldn't be the first time) but I would argue that there is sufficient
confusion around the issue that perhaps the whole subject deserves
treatment in errata.  

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

I'm not aware of anywhere in the spec that treats AllowCreate as a
consent issue - I would have thought that consent was wholly dealt with
via the Consent attribute on requests and responses.

Consider all this from the point of view of someone like myself who is
attempting to develop a product that implements this specification.  I
don't have the luxury of knowing all the deployment specific issues and
my goal is to develop a product that will accommodate all such issues as
well as interoperate with any other SAML2 implementation regardless of
their deployment issues.  

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

Point taken.  But let me play the devil's advocate for a second:
wouldn't it be possible to link in that situation by having the SP
authenticate the user and then use NIM to register a SPProvidedID?
Granted it's a funky usage but I don't recall anything in the spec that
precludes it. 

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

I guess it's not so obvious to me and I was trying to interpret the spec
in a way that would mitigate such non-interoperable deployment modes.
Maybe that's too far fetched.  

If there are such mutually exclusive deployment modes, it's not obvious
to me what they are.  What's the differentiating factor?  Name id format
support?  Operational modes as defined in the conformance spec?  Or
something else?

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

I don't think it's that straightforward.  Support for the linking use
case is sprinkled throughout the spec and not always isolated to the
"persistent" format.  

> > 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'll disagree again - I read the wording in the specification very
differently.  Apparently I'm wrong and can accept that :)  But the issue
needs clarification I think. 

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

I can understand the reasoning there but it seems like we've gotten
stuck in the middle somewhere.  It seems the 'persistent' format
approaches being its own protocol in places (a la ID-FF) but in other
places it's exactly the same as the other formats.   And it's very fuzzy
(to me anyway) how it all fits together - when the rules apply and when
they don't.

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

I don't follow this - what do you mean by provisioning?  Provisioning a
new account?  Provisioning the identifier (pair wise or otherwise)?
Something else?

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

I see what you are saying but it seems odd to me to have messages that
are really only informational that the other party can act on, or not.
And actually my question was more about the SP using NIM to register a
SPProvidedID.  

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

And, as a product developer, that's what I have a hard time with.