Minutes IETF103: oauth
minutes-103-oauth-00

Meeting Minutes Web Authorization Protocol (oauth) WG Snapshot
Title Minutes IETF103: oauth
State Active
Other versions plain text
Last updated 2018-11-19

Meeting Minutes
minutes-103-oauth

# 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

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