Minutes for OAUTH at IETF-94
minutes-94-oauth-1

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.