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

["Eve L. Maler" <Eve.Maler@Sun.COM>]

Wasn't there an animated movie with talking mice called The Secret 
of NIMH?  For us, I guess it would be the Secret of Name Identifier 
Management and, uh, Hacking...

In your suggested <Terminate> wording, the various kinds of 
sender-imposed state are mentioned in illustrative fashion, which 
injects a little implementation realism into the normative text 
without overwhelming it or making everyone do pairwise IDs.  That 
part doesn't seem too squishy.  The AllowCreate wording seems quite 
a bit squishier (but maybe that's because it would benefit from a 
bit of editorial tightening-up).

It certainly gets us a little farther down the path of discussing 
the desired normative strength rather than wrangling over the 
meanings of all the terms.

	Eve

Scott Cantor wrote:
> I'll follow up this thread for my action item since I captured some of the
> issues here anyway. I know it's a little long, but I really think we're
> close here, so please read.
> 
> 
>>- we might want to strengthen the proviso in the NIM protocol about
>>transient identifiers not "generally" being used with it
> 
> 
> I don't know what exactly my point was for saying "typically not" in the
> spec. It simply makes no sense. So I'm going to argue that it should be
> strengthened to MUST NOT so implementers don't have to guess.
> 
> [SAMLCore]
> Line 2419-2420 Change to:
> 
> "This protocol MUST NOT be used in conjunction with the
> urn:oasis:names:tc:SAML:2.0:nameidformat:transient <NameID> Format."
> 
> I'll deal with AllowCreate subsequently.
> 
> 
>>- we definitely should clarify whether the SPProvidedID feature in NIM
>>attaches the alias to "this principal" (the current text) or "this NameID"
>>(my intent, not precluding or requiring the IdP from attaching it to other
>>applicable NameIDs for the same principal)
> 
> 
> Some general NIM notes...
> 
> Brian correctly notes that even if you start with a global database of X.500
> names, supporting IdP or IdP Extended mode means you support NIM. That means
> your implementation MUST accommodate the SPProvidedID construct regardless
> of format (excluding transient, as noted above). That of course means per-SP
> state, no argument from me. That's why the light modes were adopted, in
> which NIM is not supported.
> 
> I note that the language of NIM (I'm picturing talking mice here, free SAML
> mousepad to anybody that gets the reference) is really in terms such that my
> question above isn't exactly relevant. If an IdP is planning to switch from
> one format to another, the point of NIM is to tell the SP that by sending it
> a message to that effect, and of course in that case, sure, the SPProvidedID
> is going to be preserved across formats because it's really "changing" one
> NameID into the other, not so much using both at the same time.
> 
> So I think it's an implementation decision how one would handle multiple
> identifiers for one principal (used with a single SP). That use case wasn't
> really captured, but it's probably reasonable to assume that such an IdP
> would want to attach the alias to all of them. I think this pushes well into
> implementation guidelines though, and an SP that's making use of this
> feature is probably only going to handle one NameID at a time anyway.
> 
> Finally, let me add a note about termination (SP initiated in particular). I
> just can't see a reading of this that forces the IdP to do anything, and
> this is not a change from ID-FF. In fact the text is almost exactly the same
> (and I don't think I wrote that text, even though I edited part of 1.2).
> Nothing in ID-FF says anything normative about the IdP doing anything, so I
> left it the same.
> 
> The problem is, how does that make any sense if AllowCreate is to matter? I
> think it could be argued (I guess Greg did) that we need to strengthen that
> text in such a way that it is more directly peered with the use of
> AllowCreate. Not so much in the sense of requring they be used in tandem,
> but describing the conditions under which they both apply (and by
> implication when they don't).
> 
> So, consider this expansion of lines 2475-2479 based on a concept I'll call
> sender-imposed state.
> 
> ---
> 
> "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 or (in the case of an
> identity provider) it will no longer issue assertions to the service
> provider about the principal."
> 
> "If the receiving provider is maintaining sender-imposed state associated
> with the name identifier, such as the value of the identifier itself (in the
> case of a pair-wise identifier), an SPProvidedID value, the sender's consent
> to the identifier's creation/use, etc., then the receiver can perform any
> maintenance with the knowledge that the relationship represented by the name
> identifier has been terminated."
> 
> "Any subsequent operations performed by the receiver on behalf of the sender
> regarding the principal (for example, a subsequent <AuthnRequest>) SHOULD be
> carried out in a manner consistent with the absence of any previous
> sender-imposed state."
> 
> ---
> 
> Now, cynics should note that this re-assigns the problem to the definition
> of "sender-imposed state". And that the spec imposes some (SPProvidedID),
> assumes some that could be addressed in a manner not requiring actual state
> (a pair-wise value), and leaves the rest to implementations
> (consent-oriented value-add). Is this better? I don't know.
> 
> 
>>- reaffirming that AllowCreate false was definitely not intended to
>>preclude use of pre-provisioned identifiers as in many current use cases
> 
> 
> Let me try some alternative text and carve out transient in the process,
> also based on the new text for termination, obviously.
> 
> [SAMLCore]
> 
> Replace definition of AllowCreate, lines 2123-2129:
> 
> "A Boolean value used to indicate whether the requester grants to the
> identity provider, in the course of fulfilling the request, permission to
> create a new identifier or to associate an existing identifier representing
> the principal with the relying party. Defaults to "false" ir not present or
> the entire element is omitted."
> 
> Replace lines 2143-2147 and insert new text at line 2130 (beginning of the
> explanatory text):
> 
> ---
> 
> "The AllowCreate attribute is used to control the creation of state
> maintained by the identity provider pertaining to the use of a name
> identifier or (or any other persistent, uniquely identifying attributes) by
> a particular relying party, for purposes such as dynamic identifier or
> attribute creation, tracking of consent, subsequent use of the Name
> Identifier Management protocol (see section XX), or other related purposes."
> 
> "When "false", the requester constrains the identity provider to only issue
> an assertion if such state has already been established or is not deemed
> applicable to the identifier. Thus, this does not prevent the identity
> provider from assuming such information exists outside the context of this
> specific request (for example, establishing it in advance for a large number
> of principals). A value of "true" permits the identity provider to take any
> related actions it wishes to fulfill the request, subject to any other
> constraints imposed by the request (the IsPassive attribute, for example)."
> 
> "The use of the AllowCreate attribute MUST NOT be used and SHOULD be ignored
> in conjunction with requests for or assertions issued with name identifiers
> of the urn:oasis:names:tc:SAML:2.0:nameid-format:transient Format (they
> preclude any such state in and of themselves)."
> 
> ---
> 
> Related changes could be made to the profiles doc where the old AllowCreate
> text is simply repeated, but I'd just as soon pull it from that profile or
> refer to core.
> 
> I think this is more explicit, certainly, but I hope it does a better job of
> suggesting what the "trigger" is for looking at AllowCreate, the creation of
> local state. If your implementation provides for no such state in the mere
> issuance of assertions (dynamic creation of IDs, tracking consent, ...),
> then you're not going to have to impose that constraint.
> 
> I also think if that's not sufficient to get the interop people want,
> another profile around getting and tracking principal consent (which will
> directly trigger all those "ifs and buts" I wrote in above) is needed and is
> better than baking it into the lowest level of the spec or the SSO profile.
> 
> Sigh. Thoughts?
> 
> -- Scott
-- 
Eve Maler                                      eve.maler @ sun.com
Sun Microsystems - Business Alliances     x40976 / +1 425 947 4522