[Openid-specs-ab] Spec call notes 21-Sep-15

[Mike Jones]

Spec call notes 21-Sep-15

Mike Jones
Edmund Jay
William Denniss
John Bradley

Nat Sakimura
Brian Campbell
Nov Matake

Agenda
                HTTP-Based Logout
                Session ID in Back-Channel Logout
                Session ID in HTTP-Based Logout
                New Issues
                Fast Identity Verification
                Workshop before IIW
                Tokyo workshop after IETF 94 Yokohama
                Certification

HTTP-Based Logout
                Mike described a request from Microsoft developers to be able to have multiple logout URLs for HTTP-based logout
                                Just like you can have multiple redirect URIs
                Mike described two possible approaches:
                                either having parallel arrays - one logout URL per redirect URI
                                or reusing the redirect_uri value with a logout query parameter
                William talked about Google having related Client IDs, which share approval state
                                So the front channel logout spec would work fine for them as-is
                John talked about the principle of pushing complexity to the server
                                No adding client semantics to overload an endpoint
                Mike will ask the developers about having multiple client IDs instead

Session ID in Back-Channel Logout
                It gives you an identifier for the user agent, which you don't have on the back-channel
                John says that it may or may not be a correlation handle

Session ID in HTTP-Based Logout
                Mike: Do we want to pass an optional logout token instead of an optional session ID?
                                This would make the back-channel and front-channel approaches more alike
                John is worried about size issues in this approach on the front-channel
                Mike: The current approach doesn't pass an issuer & subject, which you probably actually want
                Mike will send e-mail asking people to compare the two approaches

New Issues
                #983 - Create Backchannel Logout spec
                                We should close this as a duplicate of issue #922
                #984 - Create a document explaining "single logout" semantics
                                A volunteer to write this is needed
                                William is willing to review and collaborate
                #985 - Use Bearer in token_type in Implicit Flow response example
                                http://tools.ietf.org/html/rfc6749#section-4.2.2 says that the identifier is case-insensitive.
                                So this is fine as-is.  We should discuss further whether to change the example or not.
                #979 - Discovery / Security Considerations: CSRF attack on user input identifier
                                This is about an attacker getting someone to do discovery on a bad discovery document
                                The bad document might use a legitimate site for dynamic client registration
                                The attacker then has the code and credentials to get a token at the good site
                                We have to do something so that people know they have registered at the right place
                                You don't current get the issuer identifier back from Registration
                                John thinks we have to fix this in Registration
                                It's a kind of fixation attack, which leads to a man-in-the-middle

Fast Identity Verification
                William told us that FastIDV is an optimization Google is using for OpenID Connect
                It's designed to avoid double consent if the user has already typed their e-mail address
                It's more subtle than it at first appears
                                For instance, not allow use with prompt=none
                There is no new parameter
                                If certain conditions are true, they give the request special treatment
                William wrote a draft documenting FastIDV: https://wdenniss.com/fastidv
                Conditions when FastIDV applies are in Section 4.1 - https://wdenniss.com/fastidv#rfc.section.4.1
                The effect is to skip an interactive dialog when the conditions are true
                If there's interest, it could become a specification or a deployment guide
                                Section 5 does specify new discovery values
                John stated that this is clearly the right working group
                Mike suggested that William e-mail a copy of the spec as a contribution to the working group and ask for feedback

Workshop before IIW
                http://www.eventbrite.com/e/openid-foundation-workshop-before-fall-2015-iiw-meeting-tickets-17960843366
                It is currently listed as sold out - we need to talk with Don and Symantec about that
                We believe that Adam has a conflict, and if so, couldn't do the RISC presentation
                The NAPPS session should talk about possible reorganization of NAPPS

Tokyo workshop after IETF 94 Yokohama
                We don't have any updates on the workshop
                http://www.eventbrite.com/e/openid-summit-tokyo-2015-tickets-18111127871
                Registration is not yet open for that, but there will be an English registration page
                Nat translated the Japanese event page to English at http://j.mp/cfp_oid15
                Session proposals are due by the end of the month
                People should submit them soon so the timeslots aren't taken by other things

Certification
                Edmund reported that there are a few more issues
                                Mostly about locating signature and encryption keys
                                There are issues files in the tracker for these
                                                https://bitbucket.org/openid/certification/issues?status=new&status=open

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