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

[Greg Whitehead <grw@trustgenix.com>]

See comments below.

On Apr 5, 2005, at 12:10 AM, Scott Cantor wrote:

>> I should have linked to this message from Brian Campbell as
>> part the April 5 agenda. We can discuss this thread under
>> errata or as an independent item during the call.
>>
>> http://lists.oasis-open.org/archives/saml-dev/200503/msg00000.html
>
> Synthesizing a few potentially concrete things from that thread (not to
> disparage my long-winded and mostly unsatisfactory responses that 
> people
> will so enjoy):
>
> - we might want to strengthen the proviso in the NIM protocol about
> transient identifiers not "generally" being used with it

Agreed.

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

I believe it should be the principal. If the IDP assigned NameID is 
updated, you shouldn't throw away the SP assigned NameID.

> - reaffirming that AllowCreate false was definitely not intended to 
> preclude
> use of pre-provisioned identifiers as in many current use cases

Agreed.

> - whether persistent in and if itself assumes dynamic creation during 
> SSO (I
> think we're agreed it doesn't)

Right, persistent NameIDs can be provisioned in-band or out-of-band.

> - whether persistent attribute-based identifiers introduce a loophole
> sufficient to render using AllowCreate pointless anyway

While it may be true that attributes may foil the use of pseudonyms in 
persistent or transient NameIDs, by revealing too much information, I 
don't see how they render AllowCreate pointless. The point of 
AllowCreate is to prevent an assertion from being generated in response 
to an AuthnRequest under certain circumstances: namely, when the 
requester has not already been assigned a persistent identifier for the 
user (in-band from a previous authentication, or out-of-band by some 
other means). In other words, AllowCreate=false is meant to prevent the 
requester from learning a persistent name for a user that they don't 
currently already know. In Liberty ID-FF we called this sharing of a 
persistent identifier 'federation' and the flag on AuthnRequest was 
called 'federate'.

-Greg

>
> -- Scott
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php