Login Federation

[John Ehn]

During the session cookie request, we are notifying the RP of the isLoggedIn
attribute.  The RP will already have this value (along with the
matching OpenID Identifier) because it was notified of the value when the
isLoggedIn attribute was updated.  The RP can then build a cookie that
matches the User Agent to the Identitifier.

Because AX unsolicited responses have to be verified with the OpenID
Provider, forcing the RP to look up the Identifier using the value of the
isLoggedIn attribute ensures that we are matching up to the correct
Identifier, and removes a potential security hole.

For RP-initiated log-out scenario, you can have the RP update the isLoggedIn
attribute using Attribute Exchange.  Since the change requires user
approval, this will ensure a rogue RP cannot accidentally log the user out.

Although browser extensions are great ideas, not all types of browsers can
load extensions.  For instance, a mobile phone or web tablet may not have
the ability to install Verisign's Seatbelt.  This is intended to be a way to
have SSO-like functions without modifying the User Agent.

Also, this is not technically a SSO implementation.  We are not assuring all
the RPs that this User Agent owns this OpenID.  Only that we think it does.
This means that each RP will have to perform its own (automated) OpenID
login process when the User Agent visits the site.  Since the cookie makes
it easy to figure out which OpenID Identifier to use, the process becomes
easy.

Thanks,

John

On 2/20/08, Tatsuya KATSUHARA <t-katsuhara at nri.co.jp> wrote:
>
> Thanks!
>
> 1st: How to input OpenID implicitly.
> 2nd: How to SLO from RP/OP(How to notify to RP or OP).
>
> For 1st, you issue site-specific session cookie and notify the value
> of *isLoggedin* attribute requested on the last? explicit login from
> RP and UA'll get the authenticated session cookie via IMG tag. I think
> federationId should include OpenID/iname, or RP get anonymous user's
> authenticated session. Do you mention it?
>
> Incidentally, I think it's enough that browser extention feeds OpenID
> to the form automatically and start with openid.mode="immedidate".
>
> For 2nd, what you say is good way. In fact SAML2.0 do SingleLogOut
> negotiation. To add another word, it would be good to add RP-initiate
> logout scenario.
>
> As I said, browser extention acheve to logout automatically. But
> SingleLogOut timing should be right unlike SingleSingIn in the view of
> security. If any, please let me know good ideas.
>
>
> In all honesty, I feel this draft is a little tricky, but whether
> OpenID that is low-coupled takes SingleSingIn/LogOut into spec or not
> is very interesting issue. I would like to know how do subscribers
> think...
>
> --
> =katsuhara <http://xri.net/=katsuhara>
>
>
> John Ehn wrote:
> > I've posted a Draft 0 version to the OpenID Wiki.  Please feel free to
> > comment and modify as needed.
> >
> > http://wiki.openid.net/Federation_Extension
> >
> > Thanks,
> >
> > John
> >
> > On 2/19/08, John Ehn <john at extremeswank.com> wrote:
> >> Brett,
> >>
> >> No formal process.  All RFC through the mailing list.
> >>
> >> Thanks,
> >>
> >> John
> >>
> >>
> >> On 2/19/08, Brett Carter <brett at rdnzl.net> wrote:
> >>> John Ehn wrote:
> >>>> Sounds good.  I'm working on a draft.  Once it's in a readable state,
> >>>> I'll post it for comments.
> >>>>
> >>>> Thanks!
> >>> Is there a formal process for submitting a proposal yet?  Or are we
> just
> >>> going with RFC format for now?
> >>> -Brett
> >>>
> >>
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > specs mailing list
> > specs at openid.net
> > http://openid.net/mailman/listinfo/specs
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20080220/98f1a9cf/attachment-0002.htm>