[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] IdP Discovery
Scott Cantor wrote: > > So clearly, ID-FF did not really distinguish the use cases well, no, if you mean use cases in terms of (a) using CDCs for IDP disco/intro, and (b) using cookies to maintain "local session state" and/or even to indicate if there exists a "session" (i.e. presently logged-into) with a given IDP, then my reading of the ID-FF specs here this afternoon is that we did delineate between (a) and (b). For example, in ID-FF Impl Guidelines v1.2.. http://www.projectliberty.org/liberty/content/download/322/2378/file/liberty-idff-guidelines-v1.2.pdf ..we say.. 92 In the Liberty context, cookies might be used for maintaining local session state, and cookies are used in addressing the introduction problem (see Common Domain Cookie in [LibertyBindProf]). ..where "might" was intended to indicate "we don't address it, somebody else does", but we probably should have more explicitly said that local session state maintenance was out of scope of ID-FF. we do/did have an explicit definition of local session state in Lib Glossary v1.4 (the apropos gloss for ID-FFv1.2), but perhaps should've noted there the out-of-scope-ness of it (which is a somewhat subtle concept given that the overall notion of ID-FF is SSO). > Of course, none of that stuff got reproduced in any SAML docs, we > just copied the profile itself, hm, yeah, seems to be an oversight in retrospect. > so it's fair to say we have ambiguous intent > and need an errata one way or the other, or it's being explicitly left to > deployers. the latter is certainly the implicit case now it seems. Wrt an errata, we could do it that way, and/or see about producing an Implementors' Guidelines similar to the ID-FF one. =JeffH
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]