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

[John Bradley]

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> 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> のメッセージ:
> 
>> 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
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> _______________________________________________
> Openid-specs-ab mailing list
> 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/20130524/6ceabcc5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4507 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130524/6ceabcc5/attachment.p7s>