RE: [security-services] Forwarding thread on "previously established an identifier usable by the requester"?

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

> Does being an IDP basic or extended imply that you must keep per-SP
> state about the IDP side of the identifiers too (in order to honor
> AllowCreate)?

Not unless you add SP-initiated name registration, so with regard to
AllowCreate, I see no such requirement. If people see one, then we need to
add that to the spec, because I don't see it anywhere, or see how anybody
could come to that conclusion. So that means there's obviously confusion
over this point.

What I see is the spec trying to say (badly) is that IF you maintain such
state, THEN AllowCreate means..... That's a big IF, especially when dealing
with the more typical kinds of identifiers.

> Maybe keeping state is too strong as there way be ways to
> honor AllowCreate w/out actual state but I think I gravitate to
> describing it as keeping state because that that's what the external
> behavior of the IDP looks like.  

I'm fine with that approach. Because if I'm not maintaining SP-specific
state, then I don't see where in the spec I'm obligated to act like I am
externally.

> Does being a light IDP mean that you must ignore AllowCreate?

See other note, but I vote no.

> Can a light IDP issue identifiers with the 'persistent' format?  If so,
> is AllowCreate meaningful in this situation?

See other note, but I say yes, if you're willing to live with a suboptimal
implementation of it. I doubt AllowCreate could be meaningful, but....I
don't what else to say but it depends. Light says what you don't support
(NIM), not how you implement what you do support.

> If so, is operational mode inferred from the available endpoints in
> metadata?  If not, what is it based on and how is an SP to know how the
> IDP will treat AllowCreate an NIM?

How is an SP to know that an IdP supports SHA-256 hashes in its signatures?
It can't. It has to be told that. Same here. I don't see why one being
"above" the SAML stack and the other "below" changes the fact that both are
out of scope of the spec.

However (and I granted this), if you want real interop, you better have a
profile. SHA-256, of course, is interoperable. Use of AllowCreate at the
level we're talking won't be until somebody defines semantics that go beyond
what's there. Or we bake those semantics into the core spec and force
everybody to follow them.

Since we didn't, I think a profile is the right approach here.

> A little off topic here but I don't see how NIM can be used to change
> the format of an identifier - the <NewID> element in a
> <ManageNameIDRequest> is of type string.  Seems like all you can do is
> change the value.

Format is a SAML thing. The NewID can have a different Format attribute
value from the old one. That effectively changes the Format of the NameID. I
saw no reason to preclude this within the protocol, since core simply
doesn't care what Format is involved, transient being about the only
exception case.

> It sounds like it is still at the IDPs discretion as to if they want to
> maintain such sender-imposed state.  It seems a bit of a contradiction
> that there are situations where a sender can impose state but cannot
> know if the receiver is in fact honoring that state.  Maybe I'm missing
> something here - I don't know.

Maybe impose is the wrong word to use. The sender can't impose state except
in the case where there's no other way to honor the request. SPProvidedID is
the only place in core I see this happening currently, and that happens
*after* all this stuff.

What I meant was, the sender can't impose state, but might wish to signal to
the IdP that it shouldn't create such state if it can't fulfill the request
without doing so. Otherwise, you can't clarify the spec any way other than
mandating particular implementation strategies.

> The wording feels better on first read but I'm not sure it doesn't just
> push the problem to a different level.

It does. My only goal was to try and unify the treatment of Terminate and
AllowCreate more, but I'm still not going the extra mile here.

> Who decides if it is not deemed applicable to the identifier?  If this
> decision isn't normative, then different implementations will have
> different interpretations and that can lead to interop problems.  

I'd like to see an actual explanation of what it is that your SP is going to
do based on AllowCreate that somehow "breaks" because of what an IdP does
internally. (Or vice versa.) I'm not saying you're wrong, but specifics
would help me understand this a lot better.

If I send false, then it seems to me the goal is nothing more than to
communicate that to the IdP, not force it to behave in a particular way.
This isn't the same as IsPassive, as I keep trying to note.

> To me, what is important is what behavior the SP can impose on the IDP
> with the attribute.  How is the SP to know if the IDP implementation
> provides such state in the mere issuance of assertions?

The same way it knows lots of other things, out of band. There are all kinds
of things like that, seems to me.

> Is it completely arbitrary and at the discretion of the IDP?  Is it 
> a function of name identifier used?  Is it a function of the operational
> mode (light or basic/extended)?  Or is it something else?    

I think it's completely at the discretion of the IdP and always has been.

> All of the ID-FF implementations I've seen used the Liberty equivalent
> of the AllowCreate attribute quite explicitly on the SP side.  The SP
> would only tell the IDP to allow creation of an identifier if the
> principal had authenticated locally at the SP and had not previously
> federated his/her identity with that IDP - so the SP knew it was linking
> accounts as a result of the SSO.  As far as I could tell it wasn't about
> user consent it was about having a little control over the state of
> linked user accounts.    

Ok, then explain to me how anything you wrote there has anything to do with
the IdP side. What MUST I do? I guess I just don't see it. I never did, and
that's why this problem exists. I didn't try and codify things in the spec
that I saw no precedent for. The fact that SAML was intended to be more
general (granted, that means less interoperable in core) was merely stronger
encouragement to take that position.

> The spec is about identity so I do think it is appropriate for clear
> normative rules about how identity is represented and managed to be at
> the lowest levels of the spec.

Assuming anybody could really agreee on that in any but a narrow context, I
think that probably belongs in a profile of a spec as general as SAML should
be. In that sense, AllowCreate is no different than
AudienceRestrictionCondition. It means something general, but can be
profiled into something much more precise.

-- Scott