Skip to main content

Minutes IETF102: oauth: Tue 15:50
minutes-102-oauth-201807171550-00

Meeting Minutes Web Authorization Protocol (oauth) WG
Title Minutes IETF102: oauth: Tue 15:50
State Active
Other versions plain text
Last updated 2018-08-09

minutes-102-oauth-201807171550-00
# OAuth - Tuesday - IETF 102

Mike "Not A Presenter" Jones and Justin Richer taking notes

# Introduction by Chairs

RFC8414 - Auth Server metadata now published

OAuth Device Flow is now in ballot and scheduled for the August 2nd IESG
Telechat

Hannes and Rifaat produced shepherd write-ups for JWT BCP and MTLS today

Ekr needs to review the JWS Request doc

# Incremental Authorization by William Denniss (remote)
   - draft-ietf-oauth-incremental-authz

Asking for scopes only as needed rather than the kitchen sink up front is the
goal

   An innovation is enabling public clients to do incremental authorization
   (this was previously impossible with public clients)

includes "existing_grant" from previous requests
  - result contains union

A branch of the AppAuth libraries now supports incremental authorization APIs
   - William showed example client code using these APIs

Dick Hardt: "Nice"

There was a discussion of review comments that Torsten Lodderstedt sent to the
list
   - A distinction was made between what the user authorized versus what the
   service authorized

[There was a lot of back-and-forth about situations on which dyanmic behaviors
of permissions and scopes may vary, including differences for public and
confidential clients]

Dick: frame it as the response must include all authorization the user has
granted. Torsten: return scope with token response so the client could
determine what happens William: very good point. The spec does not say that
today and it should, and will add some text to the spec.

William: Torsten's second point is how to handle denial and discard previous
ones. I will add more text around that.

Dick: This brings up another point: how would a client discover scopes
associated with a token from known endpoints

Hannes: some clients are using token introspection to do that.

Annabelle Backman: We should avoid making the assumption that the authorization
server hasn't revoked previous consents
        - Best current practices about consent and revocation is a relevant
        topic and a whole project by itself

Annabelle Backman: do we have an access denied use case where the AS not to
deny everything.

William: today a denial keeps the existing scopes. Two different clients with
the same use could have different scopes.

Justin: OAuth 2 does not have a structural model of what a grant is; this might
be something that we want to think about.

Justin Richer: We should avoid telling authorization servers what to do in ways
that may conflict with their already conforming implementations

Justin Richer: Introspection is also complicated, as it relates to permissions
and authorizations but it is vague on who could use it. The client can use it
without going off book, but the AS should be careful on how to implement that.

William: should we document this here.

Justin: I think we should document it here.

Justin: We sometimes forget as a community how stupid OAuth client are.

Justin: one of the issues is that the data model for introspection is for a RS,
and it has extra information that the client should not know anything about.

# Reciprocal OAuth by Dick Hardt

Dick goes through the slide deck.

William: Willian Denniss thinks that it was usefull and volunteered to a do a
review

Annabel Backman: in step 4 the user has granted consent at Sonos and came back
to Alexa with an authz code.
        During this step Alexa could have received scope value from Sonos.
        Instead do that at step 5 which would be over the secure channel, where
        Alexa would exchange the authz code for an access token, refresh token,
        and Sonos' scopes

Dick: that could work. lets discuss this on the list.

Hannes: if this new flow fails, would you fall back to the previous flow.

Dick: no, it will just fail.

# Token Bindings - Brian Campbell

Brian present Token Binding:

???: Two apps on the same device; can they share the TLS connection?

John Bradley: it depends on the OS implementations

Andrey Popov: each application will have its own TLS connection, but token
binding key could be shared, but this is platform specific.

Annable Backman: regarding token binding of access token received from the
token endpoint it was not clear to me is there only one referred token or could
be more than one?

Brian: only one.

Annable Backman: it does not have to be a single access token bound to multiple
referred token binding ids, as long as there is a mechanism for a client to get
an access token that is bound to another token id from another service. Maybe
this should be non-normative text.

Brian: the text supports that already.

John Bradley: we have identified in some clustered env that it might be that
token binding is not the right answer.

Dick: One of the issues is that TLS is managed at the load balance while the
access token is at the application, so how do you get the trust where the id is
negotiated where the apps is verified.

# Mutual TLS & Token Exchange - Brian Campbell

Quick update on the latest on these drafts.

# JWT Introspection - Torsten

Quick presentation of the slides.

Justin: They deleted the bad stuff, the security discussion is going in the
right direction. I support this. This could be very useful in multiple places.