IETF 93 OAuth WG Meeting Minutes -------------------------------- Room 301 Time: 15:20-17:20 Date: Thursday, November 5, 2015 (JST) Chairs: Hannes Tschofenig + Derek Atkins (absent) Minute Taker: Kepeng Li (and revised by Hannes Tschofenig) 1) Status Update (Hannes) - PoP Shepherd write-ups by Kepeng regarding PoP architecture and PoP Key Semantics. Both were sent to the IESG already. - Charter Update Hannes to submit an updated charter based on the outcome of the discussions during this meeting. 2) OAuth 2.0 JWT Authorization Request - JAR (Nat) http://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ Nat goes through the issues raised during the WGLC reviews from Brian and Hannes. It was noted that the document could offer more background information about why a new serialization mechanism is offered. John mentioned that it could be noted that the request object travels through the browser and can therefore be modified. Brian raised a question whether the request object is only encrypted. This lead to a discussion of the difference between encryption and integrity protection (using symmetric and asymmetric cryptography). The conclusion was reached that the security consideration section needs to be updated to explain what properties the different methods for using JWS/JWE provide. Nat was also asked to provide additional text regarding replay attacks since third party signing does not allow the sender of the request object to compute a digital signature or a MAC (since Section 5.2 should make normative reference to OpenID Connect. There is currently no conflict with the PoP key distribution draft that uses the 'aud' parameter and the JAR document since the PoP key distribution draft currently only uses the 'aud' parameter at the token endpoint. However, Brian assumes that it will end up being used at the authorization endpoint eventually because the need to disambiguate where the token will be used isn't limited to the token endpoint (we do have this implicit thing). John mentioned that Ping Identity has used an 'aud' parameter (interpreted as a resource location) in their AS implementation on both endpoints to allow the client to indicate where it intends to use the token it's asking for, which enables the AS to apply unique policy to that token for the given resource. Justin noted that there is general utility to indicate the audience. Today people are forced to use the scope for WHAT, HOW and HOW LONG the client wants to access a protected resource. The 'aud' describes the WHAT aspect. He suggested to take it a general utility extension that is indepdent of the PoP document. Hannes added a remark that the 'aud' parameter / claim was a separate document (see https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00) and was subsequently added it to the PoP document. John said that we didn't had the wide-enough picture and we now understand things better. Section 5.2: Discussion about where to register parameters -- in the IETF document or in the OIDC spec. Section 4.2.1 defines the precedence rules. It was unclear whether this is OIDC specific or whether this is OAuth related. Nat will make a update within two weeks. Kepeng and Mike volunteered to review the draft. 3) Proof-of-Possession Key Distribution (John) http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/ John starts his presentation and focuses on the description of the threat against refresh tokens where a client is unable to secure access and refresh tokens. There have been some real-world attacks against websites that did not protect their token store properly. Of course, there is the assumption that some hardware security can be used to secure some credentials. In the initial draft we did not allow the client to change the key bound to the access tokens. A number of people want to rotate the key when they request a new access token. When we want to do that securely we need to offer PoP version of the refresh token. If an adversary gets hold The proposed resolution is the following: (a) For confidential clients the client ID/client secret is enough as a PoP feature for the refresh token. (b) For public clients we make use of PKCE as the PoP feature. It might also be a good time to extend PKCE to support an asymmetric version. Need to incorporate comments from Tony in the mailing list where he argued that we need to support TPCs. He wants to use a wrapped key since the draft is not friendly towards client creating symmetric keys locally. Tony also raises the desire to allow attestation information to be conveyed from the client to the authorization server. Hannes argues that we shouldn't not make the document TPM specific but rather to be open for other hardware security solutions. Justin argues that we need very clear rules for precedence order. Discussion about how these rules could look like and how much complexity it introduces. 4) HTTP Signing (Justin) Justin goes through his slide deck where he explains the current status with the HTTP signing concept. In his presentation he also raises open issues, such as repeated headers. Need implementations and inputs to the designs. Hannes points out that recently two groups in Sweden (Roland Hedberg, Fredrik Ljunggren, and Jakob Schlyter) offered help with the document and will work on implementations. Nat believes that this document has some relationship with sender constraint draft. 5) Token Exchange (Mike) http://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ At the Prague IETF meeting we had a good discussion about the open issues. The draft editors have been working on proposed resolutions. A new document is expected to be published soon. Brian and Mike will post to the list on how the issues have been addressed. 7) Rechartering (a) OAuth 2.0 for Native Apps (William) http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/ With this work Williams described how to securely use OAuth with native apps by utilizing new mobile operating system concepts so that the client application is not able to get access to the user provided credentials. The concept also allows the re-use of the SSO mechanism for apps developed in the OpenID Foundation to be used. Furthermore it will make the use of FIDO for apps easier since FIDO support in the OS can be utilized rather than requiring app developers to develop authentication functionality into their apps. The finalization of PKSE also helps securing native apps. Sandeep asked how to differentiate from a webview and a phishing app internal browsers. William argues that the best possible way is to see the login dialog in the first place. There is also an icon to return to the app that created the view. Tony argues that there are some patterns described in the draft do not exist any more, such as the authentication to the IdP. Erik argues that it solves a lot of issues in the enterprise use case but the UI aspect has to be looked at. Poll: 16 persons for doing the work / 0 persons against / 2 persons need more info (b) Security Extensions & Fixes (John) John argues that the new charter needs to include work like the asymmetric PKCE extension, token binding for refresh tokens; redirection best practices, and post message response mode to replace fragment. Kepeng subsequently brielfy explains the sender constraint. Hannes notes that this is based on existing implementation. Poll: 17 for/0 against/0 need more info (c) API Management (Phil) Phil explains the concept of API management where a resource server registers configuration data about the protected resources to the authorization server. This is functionality introduced by UMA as resource set registration. Justin and Phil argue that there are requirements beyond what has been developed within UMA. The relevant UMA document can be found here: https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html Poll: 6 for / zero against / 9 persons need more information. (d) JWT Claims (Mike) Mike gives an example of the need to define new JWT claims based on draft-jones-oauth-amr-values draft. Poll: 9 for / zero against / 6 persons need more information. (e) Device Flow (William) William goes through his short presentation and explains the device flow that was part of the OAuth 2.0 specification but then got moved into a separate draft. The document later expired but has been implemented by various companies, including Facebook and Google. Poll: 16 for / zero against / 2 persons need more information. (f) Discovery (Nat) Nat explains his document as an example of the work that has to be done in the area of discovery, which is a topic that has been identified as necessary for interoperability since many years but so far there was not time to work on it. Mike, John and Nat are working on a new document that describes additional discovery-relevant components. Poll: 19 for / zero against / 4 persons need more information. Hannes will post an charter proposal.