[OAUTH-WG] IETF 93 OAuth WG Meeting Minutes

[Hannes Tschofenig <[e-mail]>]

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.