# 1st OAuth meeting at IETF 103, 5-Nov-18
Notetaker: Christopher Wood
## Introduction (Hannes)
## Token Binding (Brian) - draft-ietf-oauth-token-binding
Torsten: option 3 (slide 7) is the pattern for native apps or OAuth client that
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
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?
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
Ben: Is question that we cannot currently support SPAs, or that we cannot ever
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
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) --
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
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
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
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
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
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
Brian didn't believe that Justin's comment was
Torsten went to the microphone to express support for WGLC
He stated that he believes what's in the draft is a
Hannes said that the chairs will send a WGLC announcement to the
Brian Campbell - draft-ietf-oauth-mtls
See presentation at
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
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 email@example.com 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
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
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?
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