[Openid-specs-ab] Another session management question: Per-user session state change notifications

Mike Jones Michael.Jones at microsoft.com
Sat May 25 02:18:46 UTC 2013


My main point is that we should probably say that in some implementations “changed” events will occur only when changes to the user’s session occur whereas in other implementations, they may also occur as a result of changes to other sessions between the user agent and the OP as well, and that RPs should be prepared for either eventuality.  Any disagreement with that?

                                                            -- Mike

From: John Bradley [mailto:ve7jtb at ve7jtb.com]
Sent: Friday, May 24, 2013 7:07 PM
To: Nat Sakimura
Cc: Mike Jones; openid-specs-ab at lists.openid.net; Naveen Agarwal
Subject: Re: [Openid-specs-ab] Another session management question: Per-user session state change notifications

I seem to recall that there were issues with tracking them separately and changing state when any user in the browser logged in or out of the idp was going to be simpler for the IdP.

Remember we want people to build it, so simplicity and reliability count.

I am guessing that some browsers like Chrome which have a notion of personas with logged in sessions might be able to do a better job of separating the sessions.

John B.

On 2013-05-24, at 7:19 PM, Nat Sakimura <sakimura at gmail.com<mailto:sakimura at gmail.com>> wrote:


If Alice and Bob are different entities, they should be independent.

=nat

May 25, 2013 6:52、Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>> のメッセージ:
Another one for you, Breno and Naveen…

Assume Alice and Bob are both have sessions within the same user agent at the same RP using the same OP.  Currently, the session management spec assumes that session state notifications caused by changes to either of Alice’s or Bob’s session will cause “changed” notifications to be sent to both of them, correct?  Developers I’m speaking with are saying that they’d like it to be legal for Alice to only be notified of changes caused by her session and for Bob to only be notified of changes caused by his session.  This would cut down on the number of false positives, which result in unnecessary “prompt”: “none” reauthentication requests.

Is there any reason not to say that legal implementations may do this?  Or is there some technical reason that Alice MUST always be made aware of changes to Bob’s session, and vice versa?  Might it be that there’s no way of knowing who’s asking within the user agent, and so both have to be notified of changes caused by either?

                                                                Thanks all,
                                                                -- Mike

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130525/64d3b9d0/attachment.html>


More information about the Openid-specs-ab mailing list