Correction regarding the API Protection new charter item. There is the Thomas Hardjono IETF draft (referenced in my pres) from earlier this year which could be used to work on. Justin was indicating the UMA draft may be more recent.
Phil > On Nov 6, 2015, at 05:03, Hannes Tschofenig <hannes.tschofe...@gmx.net> wrote: > > Here are the meeting minutes from the f2f. Please drop us a message if > there is something missing or incorrect. > > --------- > > 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 (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. > > Brian also pointed out that there is a conflict with the PoP key > distribution draft that uses the 'aud' parameter. John noted that > currently the 'aud' parameter is used towards a different endpoint, used > as a query parameter, but it would probably be good to take this into > account now. > > 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 and then we 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 > > Since there is currently no draft available discussions start about > the exact content. > > 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. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
