Re: [security-services] IdP Discovery

[Jeff Hodges <Jeff.Hodges@neustar.biz>]

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