[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"?
On Apr 5, 2005, at 10:42 AM, prateek mishra wrote: > Thanks for the characterization below, it confirms to me that > AllowCreate deals with issues that the specification we otherwise > avoid as being at the "next layer": the when and how of identifier > creation, sharing, flows between partners, lifetimes etc. > > I think the best thing to do would be to capture your characterization > and limit or discourage its use outside certain narrow contexts (for > any identifier other than persistent??). I think there are a couple of choices: 1) Limit AllowCreate to the 'persistent' format (or other formats that dynamically assign persistent IDs, as Scott suggests), which should be sufficient to satisfy the original Liberty requirement (please speak up Liberty folks, if you disagree) 2) Let AllowCreate apply to all non-'transient' (or 'transient'-like) formats, with the meaning that it governs creation of the relationship where the non-transient IDs are shared (trying hard not to use the term 'federation'). -Greg > - prateek > > [Grw] > > 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'. > > [\Grw]