[Openid-specs-ab] Spec call notes 3-Oct-16

[Nick Roy]

I'm very interested to find out what Prateek's group's analysis shows.

Revoking the client keys used to do token binding might be a great way 
to nuke everything unilaterally, which would be in the control of the 
user.  If the server had a way to request that the user approve 
revocation of the client keys used with sessions from that server, that 
would be even better.

Nick

On 10/4/16 4:46 PM, Edmund Jay via Openid-specs-ab wrote:
> Spec call notes 3-Oct-16
>
> Nat Sakimura
> Edmund Jay
> John Bradley
> Phil Hunt
> Prateek Mishra
> Dale Olds
>
>
> Agenda
>     Meeting time on WG page
>     Session and Logout specs
>
>
>
> Meeting time on WG page
>     There is a mismatch of the Monday meeting time on the WG page at 
> http://openid.net/wg/connect/
> between the calendar and the text. It's 3PM PT on the text and 4PM on 
> the calendar. This is due to time
> changes in the Pacific time zone.
>     It's decided that the Monday meeting time will be pegged to 8AM 
> JST Japan time, which doesn't change.
>
>
>
> Meeting Notes from 29-Sept-16
>     Nat asked if the meeting notes from the September 29, 2016 meeting 
> is OK since he had an unreliable
> connection at the time.
> There were no objections, so minutes will be posted to the list.
>
>
> Session and Logout specs
>
> Prateek and company are still researching "strong logout" use cases. 
> Where does strong logout makes
> sense and what needs to be done.  Will try to send a report to the 
> group by end of next week.
>
>     There were no updates to the logout specs.
>
> Questions were raised about whether the SAML single logout mechanism 
> is adequate. It depends
> on the reliability of the transport.
>     The group discussed ways on how to make it more robust. One 
> suggestion was to have a way to
> replay transaction logs. But it might introduce privacy issues.
>     The group discussed the costs of checking the transactions versus 
> keeping state on the RP versus
> session extension via OAuth refresh token.
>     There are use cases such as financial institutions and fleet 
> (shared) devices which require really strong
> logout. There are also uses cases where best effort logout is good enough.
>     RPs subscribing to logout events need to know it's getting the 
> events. It needs guaranteed delivery of
> event notification.
> Another way of checking session is to programmatically do a logout and 
> login right after. This method
> may introduce a time dependency since logout event may happen after 
> the login. The RP needs a way
> to figure out the current state.
> Front channel logout is synchronous but not dependable and browser 
> could shut down any time.
> Backchannel is asynchronous but will have time dependency.
>     The logout event needs to be based on session instead of the 
> subject (user). A suggestion was to have the RP
> propose a session identifier to the OP. This way, the RP only needs to 
> keep track of it's own session identifier
> which it understands versus keeping track of another one from the OP. 
> The RP could also keep a list of
> canceled sessions within a certain time period instead of all the 
> active sessions.
>
>     Then the group discussed about token revocation. There is a need 
> to signal that long lived tokens (such as those on
> mobile devices) are no longer needed. There needs to be a way to 
> signal termination of tokens with finer
> granularity (web app tokens vs mobile app tokens, etc...)
>
>     The IdP is best able to correlate where the sessions originate from.
>
>     It's decided that it's better to develop all the separate use 
> cases and split the work into smaller chunks to fit those
> cases.
>
>
>
>
>
>
> _______________________________________________
> 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/20161005/284a8a10/attachment.html>