Another attempt at AllowCreate cleanup

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

Another try at some better text. I took a break to see if coming back to it
cold would provide some new ideas. A lot of this was in my last proposal,
but I added some language motivated by some of my discussions with Brian.
Hopefully it's not *too* much text now....

[SAMLCore] Authn Request Protocol

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" if 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 may be used by some deployments to influence the
creation of state maintained by the identity provider pertaining to the use
of a name identifier (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 tries to constrain the identity provider to
issue an assertion only if such state has already been established or is not
deemed applicable by the identity provider to the use of an 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 and policy (the IsPassive attribute, for example).

Generally, requesters cannot assume specific behavior from identity
providers regarding the initial creation or association of identifiers on
their behalf, as these are details left to implementations or deployments.
Absent specific profiles governing the use of this attribute, it might be
used as a hint to identity providers about the requester's intention to
store the identifier or link it to a local value. A value of "false" might
be used to indicate that the requester is not prepared or able to do so and
save the identity provider wasted effort.

Requesters that do not make specific use of this attribute SHOULD generally
set it to "true" to maximize interoperability.

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
with a Format of urn:oasis:names:tc:SAML:2.0:nameid-format:transient (they
preclude any such state in and of themselves)."

---

In profiles, we need to decide what the specific semantics of the attribute
are for the base SSO profiles. Since I believe the intent was not to be
prescriptive, we should probably replace the current text there about
AllowCreate with a statement that "this profile does not provide additional
guidelines for the use of AllowCreate" and reference this text in core as
governing.

If implementers looking for explicit treatment of account linking setup need
more, than I think another profile on top of SSO is probably needed. I don't
favor more explicitness here in core.

[SAMLCore] Name ID Mgmt Protocol

Roughly similar to my earlier suggestions, but I eliminated some of the new
terminology since it didn't seem to help anything.

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

As I suggested before, this rules out use of NIM for transient, which makes
no sense.

Replace lines 2475-2479 with:

---

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

Termination is potentially the cleanup step for any state management
behavior triggered by the use of the AllowCreate attribute in the
Authentication Request protocol (see section XX). Deployments that do not
make use of that attribute are likely to avoid the use of the <Terminate>
element or would treat it as a purely advisory matter.

Note that in most cases (a notable exception being the rules surrounding the
SPProvidedID attribute), there are no requirements on either identity
providers or service providers regarding the creation or use of persistent
state. Therefore, no explicit behavior is mandated when the <Terminate>
element is received. However, if persistent state is present pertaining to
the use of an identifier (such as if an SPProvidedID attribute was
attached), the <Terminate> element provides a clear indication that this
state SHOULD be deleted (or marked as obsolete in some fashion)."

---

Certainly lots more (or less) could be said, but this text mostly doesn't
change the spec wording normatively except in a couple of edge cases
involving transient (and of course it softens the MUSTs around AllowCreate).
I think it's tough to do much more without going beyond errata or adding new
profiles.

Brian and I both seemed to agree that one mistake we made was not carving
out SP-initiated NIM in conformance. Because that's the most explicit
indication of persistent state maintainence in the spec, so the real
difference between lightweight and basic was probably there.

After all the cycles spent on this, I would suggest that something based on
this text be adopted or others step up to provide alternate views and argue
for them based on specific proposals or profiles. I hope at least that this
text clarifies what implementers really have to do (not much) to follow the
letter of the spec. What they *should* support of course is a matter for
product marketers to decide, I guess.

-- Scott