Minutes IETF104: oauth
minutes-104-oauth-00
Meeting Minutes | Web Authorization Protocol (oauth) WG | |
---|---|---|
Date and time | 2019-03-25 15:10 | |
Title | Minutes IETF104: oauth | |
State | Active | |
Other versions | plain text | |
Last updated | 2019-04-12 |
minutes-104-oauth-00
Thanks to Tony Nadalin for the minutes. Monday ====== * Chairs Update – Hannes & Rifaat (10 min) Overview of agenda and current drafts that are in play. Dick Hardt switched jobs and need to find out what is going on with the Distributed Oauth. Device flow has had an update but William is not here, there was discussions at the Oauth Security Workshop that will make it into a new draft. JWT BCP is with AD and all area feedback has been incorporated. Brian needs to update Token-Exchange Reminder that there are conference calls every 2 week, please join if you want to discuss anything. * Security Topics & JWT Introspection - Torsten (45 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ Its an update to the Threat Model and Security Considerations documents and also the Oauth 2.0 Security Considerations documents. What has happened since last meeting, 4 revisions? Limit usage of implicit grant. More text of refresh tokens, refined the attack model Not done yet. Grant type PSWD to be deprecated – call in room showed in favor 10 none against Need to provide alternatives to lots of folks using this grant Move to public key crypto for authentication - call in room showed in favor8 none against PKCE is now mandatory and also frees up STATE back to application. call in room showed in favor 8 none against Recommend PKCE more S256 over NONE - call in room showed in favor 10 none against There is another SPA specification but not yet completed. Discussion over the if there was a consensus call to deprecating the implicit flow, Mike says there was not a call, others say there was, so Chairs to take this to the list. There was a request for a die-die specification https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ Improves RFC 7662 , used for high assurance use cases such as payments and electric signing, 7662 does not take into account signing the responses Not many changes since Bangkok, small stable draft Request to change this into a more generic specification to the list, so 1 response to keep it limited one response to open this up. So tin room hum showed hum in favor of keeping existing scope. * UMA drafts - Eve? (45 min) https://datatracker.ietf.org/doc/draft-maler-oauth-umagrant/ UMA enables cross party sharing, concept of a resource owner and resource party and these can talk to the same authorization server UMA Grant Overview Party to party, synchronous UMA Federated Authorization 1 to n Multiple RS in different domains can use an AS in another domain Different tokens Request Party token (RPT), Protection API Access token (PAT) and Persisted Claims Token (PCT) https://datatracker.ietf.org/doc/draft-maler-oauth-umafedauthz/ * JWT Usage in OAuth2 Access Tokens - Vittorio (20 min) https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/ interoperable profile for access tokens. So defining JWT profile for an access token would improve crso vendor interop Proposed JWT Access Token Layout Not to be used as ID token Validating JWT Access tokens process Thursday ======== * OAuth Workshop Update - Hannes (10 min) Link to Workshop Agenda - https://sec.uni-stuttgart.de/events/osw2019 Record attendance, invited guest speaker, hands on workshop, full agenda here https://sec.uni-stuttgart.de/events/osw2019/agenda * Browser-based App - Aaron (30 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ Written in JavaScript, no backend, require auth code flow with PKCE, no implicit flow. Browser based should not get refresh tokens Questions on the exact constraints on the proposal, should this be only browsers based? What about backend ? What is the scope of the specification? Torsten suggests that all the oauth processing can be pushed to backend, so one proposal is to make this all about Oauth in browser no about backend. So this scope would deal with receiving oauth requests, no matter if the processing takes place in the browser or in backend, cover both cases Must do exact matching on URLs Use PKCE instead of CSRF State, need to analyze current state of deployed apps, its not a simple change that can just be made. So there may need to be some words put in the BCP about state, Is S256 adequate for PKCE? Seems ok Should password grant be discouraged in BCP, its not been determined if this would be a MUST or a SHOULD. This document would prohibit use of password grant type * PoP Key Distribution - Hannes (30) https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/ new version published, seems that ACE and Oauth WG Pop tokens doscs can share same CWT usage. There is a equivalent draft in ACE to the Oauth resource parameters specification Ready for WGLC? So there may need some additional work about proving a public key without a proof. This specification seems to only be half the solution. So must prove control of the public key, how that proof is provided seems to be the question, how it crosses boundaries. There seems to be some scenarios where I may get a key on behalf of another, but you don’t have the requestors private key. Are we enabling a MIM here? This may be an ACE issue only? * MTLS Update - Torsten (10 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ Client to AS , alternative to Token Binding Changes, new abstract protocol diagrams, added new metadata for use of a SAN. Added metadata for alternative AS endpoint Need more info on how refresh tokens are used for confidential clients There sees to be some issues with the metadata changes, as they may conflict with the AS Metadata specification, so some research needs to be done. Mike says this needs to be clarified in the spec and if this is done then no issue. * Nested JWT - Rifaat (10 min) https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/ JWT within JWT, current restriction is that the outer JWT not contain claims, so this is a spec to remove that limitation. What is the motivating use case ? * DPoP Demonstrating Proof-of-Possession https://datatracker.ietf.org/doc/draft-fett-oauth-dpop/ New draft, Oauth lacks a mechanism for SPA, Prevent replay, we have mTLS and Token Binding, but support is lacking in browsers for TB Which mechanisms is this applicable to, SPA? Browser based?