# 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.