[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] IdP Discovery
Cahill, Conor P wrote: > > I can tell you that the original intent was to use a persistent cookie > as the cookie data did not indicate session status but instead > indicated recently-used IdP(s). fyi/fwiw, that, as I recall, was our first-order assumption wrt the "common domain cookie" (CDC), i.e. that use of a persistent cookie would yield by default the most useful behavior in most of the use cases we were imagining. However, a quick grep of the ID-FFv1.0 specs shows that we (a) actually left the door explicitly open as to whether a session or persistent cookie was actually employed, and (b) explicitly discussed the tradeoffs thereof. The latter (b) is discussed in the POLICY/SECURITY NOTE (line 1069-1099) of Liberty Architecture Overview v1.0 (to which I can't easily find a URL (yes, might be a good thing)) or lines 826-855 of Arch Overview v1.2-errata-v1.0), where said NOTE discussed CDC considerations/implications including persistent vs session.. http://www.projectliberty.org/liberty/content/download/318/2366/file/draft-liberty-idff-arch-overview-1.2-errata-v1.0.pdf And cookie considerations are also more generally discussed in the Liberty ID-FF Implementation Guidelines v1.2 section 2.1, with a little bit at the end of 2.1.2 wrt CDCs and policy thereof. The former (a) is addressed in Liberty Bindings and Profiles Specification v1.0 (line 1537), and also in Liberty ID-FF Bindings and Profiles Specification v1.2-errata-v2.0 (line 1990). to quote the latter... The cookie MAY be either session or persistent. This choice may be made within an identity federation network, but should apply uniformly to all providers in the network (see [LibertyImplGuide]) for more details on cookies). The referenced [LibertyImplGuide] is the one cited above. HTH, =JeffH
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]