[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Forwarding thread on "previously established an identifier usable by the requester"?
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