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

Edmund Jay ejay at mgi1.com
Tue Oct 4 22:46:25 UTC 2016


Spec call notes 3-Oct-16

Nat Sakimura
Edmund JayJohn BradleyPhil HuntPrateek MishraDale 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 timechanges 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 unreliableconnection 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 makessense 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 dependson 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 wayto 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 identifierwhich it understands versus keeping track of another one from the OP. The RP could also keep a list ofcanceled 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 finergranularity (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.  



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


More information about the Openid-specs-ab mailing list