[Openid-specs-ab] JWE and end session

John Bradley ve7jtb at ve7jtb.com
Sun Sep 4 20:30:35 UTC 2011


There are two possibilities for keeping state.

One is to use an internal table of some sort.
The other is to store it in a session cookie.  

When IdP object to maintaining state it is generaly the former as opposed to the later that they don't like.

Given that the JWT is signed by the IdP it can contain some way to connect it to whatever way the IdP is maintaining the state of the user.

The IdP could store cookies in the browser that would allow it to know where the user is logged in, to terminate via front or back channel.

Now one rub in all of this is privacy.   We have people who want to build browser agents so that the IdP doesn't know what RP the user is visiting. 
Microsoft amongst others sold this idea to the privacy people to perhaps show the advantages of u-prove.

The thing is that they now want this sort of thing.  

Another way of approaching the SLO problem is to say that it is the users browser client that should be smart enough to track where the user is logged in.

John  B.
On 2011-09-02, at 9:24 AM, Andreas Åkre Solberg wrote:

> If a provider does not keep state of issued id_tokens; how does then end session endpoint handle an incomming JWE?
> 
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110904/7ae3dc00/attachment.p7s>


More information about the Openid-specs-ab mailing list