Minutes IETF103: oauth
minutes-103-oauth-00
| Meeting Minutes | Web Authorization Protocol (oauth) WG | |
|---|---|---|
| Date and time | 2018-11-06 04:20 | |
| Title | Minutes IETF103: oauth | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2018-11-19 |
minutes-103-oauth-00
# 1st OAuth meeting at IETF 103, 5-Nov-18 Notetaker: Christopher Wood ## Introduction (Hannes) https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-chair-slides-01 ## Token Binding (Brian) - draft-ietf-oauth-token-binding https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-token-binding-00 Torsten: option 3 (slide 7) is the pattern for native apps or OAuth client that preflights requests? Brian: Sort of, but only applicable to browser-based clients. Probably could not do it in native clients. Torsten: We probably need some text describing how implicit binding works for native apps. Brian: Should be there currently, could probably be improved. Mike Jones: Part of the issue is that there is no standard token binding API for fetch? Some Google folks worked on a PR in WhatWG for that, but not sure what the status is. Brian: Not sure how to answer since it depends on what the fetch API might provide, and whether or not it addresses this use case. John Bradley: Has been some work on fetch, though the problem is that browsers are trying to foil us fighting ad networks. Will probably be limitations in what tokbind origins are specified in fetch. May need to look at other options for single page apps, e.g., WebCrypto. Browsers may not be as cooperative as one would hope. Hannes: options (1) and (2) would be unsatisfactory for this document. Brian: Maybe we can remove implicit flows as we did with MTLS? Torsten: Statement is true if javascript clients always use implicit? Brian: Wouldn’t work with code flow Hannes: How do we resolve this? Brian: Future use and validity of this draft is in question now. Torsten: Conclusion is that we can’t protect SPAs using token binding? Brian: Might not be that black and white, but it is difficult. There are a lot of conditions. Ben: Is question that we cannot currently support SPAs, or that we cannot ever do that? Brian: Both. Even with support from browser vendors, the result might not support cross-domain use case with issues surrounding tracking. Dirk: Aren't there other use cases for token binding? There are other flows where token binding provides value. Brian: Without browser support, unlikely to see widespread API support for this draft. There’s not much incentive. John: Can we achieve critical mass without broad support in the browsers? Will people support TLS implementations to support this? Annabelle: Wonder how much focus is on browsers is premature. It’s hard to imagine people using token binding given lack of infrastructure support for it. Hannes: Have discussion about whether or not to remove implicit use case now? Torsten: Can we postpone until after my presentation? Brian: Only wanted to raise the issue for now. Dirk: Architecturally there may be a preferred solution, but we should survey what’s out there to see what’s viable or not. ## OAuth Security Topics (Torsten) -- draft-ietf-oauth-securtity-topics https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01 <remove implicit flow chorus> Ben: do we need to write an implicit flow diediedie draft? Brian: Maybe have BCP recommend against it to start. Mike: Maybe not try to kill something, but try to describe security considerations about when we do and do not need to use a feature Hum: use authorization code instead of implicit flow (Room in favor) ## JWT Introspection Response (Torsten) -- draft-ietf-oauth-jwt-introspection-response https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-jwt-introspection-response-00 Jim: Partially answered question about why we’re not allowing JWT requests in addition to responses to hide things such as referrals Torsten: What would we achieve by adding a nonce to the request? Jim: Worried about cases where there are multiple servers in the backside. Torsten: Typically use a nonce for replay protection? We rely on TLS for replay detection. Torsten: RS knows which AS it is talking to, and TLS is used to talk to it. Learning which AS to talk to is not part of this use case. Torsten: Should we generalize this draft to all types of responses? Jabber: This draft needs to be clear about encrypting results/responses to a key. (?) Annabelle: (missed) Mike: Already have OpenID draft for signed OAuth responses. Doing that in this draft to doesn’t make much sense? Torsten: Will cover in next presentation. Justin: This is for the front-end channel (?) Brian: Trying to generalize in a single draft may be more academic than useful. Do not see a really use case for it in revocation responses. Against generalizing it in that fashion. ## JARM (Torsten) -- openid-financial-api-jarm-wd https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-openid-financial-api-jarm-wd-01 Annabelle: mis-characterized response mode — it does not define different representations, it defines different transport mechanisms. Query, fragment, and form post have been standardized. Representation of response in all of those is as a URL-encoded query string. Its placement in the request varies across these. Makes sense to see this as an envelope type. Are you mandating as part of spec that the JWT is transmitted via a particular manner? Torsten: Transmitted as part of form post. Annabelle: Do think it’s worth pursuing this work in OAuth. Subject matter expertise will be be found here, especially with respect to how it plays with other specs. Could look a this as a response format parameter? Torsten: Proposing combine response mode with new encoding/format? Annabelle: They are separate things. Justin: Not against this work but would like how many things are we willing to reinvent before we admit we’re doing HTTP? Mike: Against complexity when not necessary. Matthew: Interesting work, good to do here. Annabelle: Determining were to put parameters in request depends on the scope of the work. Might need to make sure that response parameters do not conflict wit JWT. Applying to other (existing) protocols where avoiding collisions may not be practical might be hard. Mike: Do not want a third parameter called response format where knowledge of three parameters is necessary to encode/decoded JWT. Developers will certainly get that wrong. Brian: Agree with Mike. Seems to mix encoding format and response mode. Possibility of combinatorial explosion is there, but may not happen in practice. Hannes: Good feedback about how this could be used beyond financial APIs, so maybe write up a draft for the group? Torsten: Or we could circulate a pointer to a document written elsewhere. ## PoP Key Distribution (Hannes) -- draft-ietf-oauth-pop-key-distribution https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-pop-key-distribution-00 Jim: Should we issue two access tokens with different permissions, and put a KeyID in req_cnf? We can rewrite to use the refresh token without issues. # 2nd OAuth meeting at IETF 103, 6-Nov-18 Notetaker: Mike Jones Brian Campbell - draft-ietf-oauth-resource-indicators See presentation at https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-resource-indicator-00 The draft has been updated to align it with OAuth Token Exchange It now allows query parameters in the URL Mike Jones asked the chairs about Working Group Last Call (WGLC) Hannes asked who had read the document About 10 people had Justin asked about the possibility of confusion between scoped and resources Brian didn't believe that Justin's comment was particularly actionable Torsten went to the microphone to express support for WGLC He stated that he believes what's in the draft is a pragmatic approach Hannes said that the chairs will send a WGLC announcement to the working group Brian Campbell - draft-ietf-oauth-mtls See presentation at https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-mtls-00 Has gone through WGLC Drafts -10, -11, and -12 addressed WGLC and developer feedback The Area Director (AD) review came in yesterday Brian talked about potential support for Subject Alternative Name (SAN) in addition to Subject DNs Mike Jones asked whether specifying multiple mechanisms will hurt interop of implementations Ekr asked whether people would advocate Subject DNs in a greenfield situation John Bradley said that here is no greenfield situation - there's plenty of X.509 legacy in play ... In Dynamic Client Registration, how do you specify what would be matched? ... European EIDAS certificates have custom extensions - do we try to match those? Brian: These choices very much imply a client data model Torsten: I agree that this is about matching at dynamic client registration time Brian would like to do something pragmatic and functional ... We can't account for all possible cases Torsten: We could define a registration parameter per SAN ... We could even define one for EIDAS matching Ekr: Managing DNs has proved to be exceedingly difficult ... That's the reason we have been moving towards SAN ... Pick one kind of SAN - We don't have to define all the alternatives Mike asked whether there were use cases for mutual TLS with SANs Brian responded that the SPIFFY (sp?) folks are doing this Brian suggested adding this capability to the document John: The authorization server will be the party doing the matching ... The server could specify what kinds of certificate fields it can match Hannes cut discussion on this topic due to time - we will take it to the list Brian asked about privacy considerations for sending certificates in the clear in TLS 1.2 Ekr said that that wasn't discussed in TLS 1.2 - we should probably add a few sentences Dick Hardt - draft-ietf-oauth-distributed-oauth See presentation at https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-distributed-oauth-00 Asked about link headers versus www-authenticate header Many existing libraries just pass www-authenticate header information through Mike Jones spoke in favor of continuing to use www-authenticate Dave Robin also spoke in favor of the use of www-authenticate headers Hannes and Benjamin suggested also asking the question to the httpauth@ietf.org mailing list Dick asked whether to use a full discovery URL or the issuer value Torsten spoke up in favor of the full URI Mike spoke up in favor of using the RFC 8414 issuer Hannes said that we need to discuss this issue on the mailing list Dick Hardt - draft-ietf-oauth-reciprocal See presentation at https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-reciprocal-oauth-00 Dick is seeing use cases in which two interacting parties are both clients and protected resources ... We have deployed this in Alexa We discussed what the proposed "reciprocal" Token Endpoint response value means and how it relates to scopes Mike asked for clarification of the intended semantics Annabelle clarified that "reciprocal" is the scope that the other party would request John said that it is the requested scope in the response Hannes asked for reviewers Mike, Torsten, and Matt Miller volunteered to review the document Omer Levi Hevroni - draft-hevroni-oauth-seamless-flow (Omer presented remotely - no presentation is in the datatracker) (The audio was nearly unintelligible) Omer is looking for comments on his draft Hannes: Do you have deployments or implementations? Omer: Yes Hannes: Nobody in the room has read the draft Hannes asked for reviewers Torsten and Dick volunteered to review the draft Aaron Parecki - draft-parecki-oauth-browser-based-apps (Aaron attempted to present remotely but there was no audio and we were 5 minutes over time) Hannes asked for reviewers Matt, Torsten, and John volunteered