Re: [OAUTH-WG] PoP Key Distribution

[Mike Jones <[e-mail]>]

Thanks for working these issues, Hannes.  I agree with your conclusion that the OAuth PoP Key Distribution spec should define the OAuth parameters for use with HTTP and the ACE OAuth profile should define those that are ACE-specific.  Therefore, we should encourage ACE spec to remove the duplicate definitions and instead reference those in the OAuth spec.

I believe that the ACE "profile" parameter is typically unnecessary and not in the spirit of normal OAuth.  Configuration information between OAuth participants is typically configured out of band and/or retrieved from the AS Discovery document (per the newly minted RFC 8414<https://tools.ietf.org/html/rfc8414>). There's no need to dynamically exchange a profile identifier when this is essentially always known in advance.  We should not include "profile".  For that matter, ACE should delete it as well, as it certainly isn't appropriate in constrained environments.

We should think some more about how we want to treat the function of the "alg" parameter and how to fully specify things for JWTs (an OAuth WG spec) while still enabling other representations when appropriate.

                                                       Thanks,
                                                       -- Mike

From: OAuth <[e-mail]> On Behalf Of Hannes Tschofenig
Sent: Tuesday, July 3, 2018 12:46 PM
To: [e-mail]
Subject: [OAUTH-WG] PoP Key Distribution

Hi all,

we have been working on an update for the draft-ietf-oauth-pop-key-distribution document in time for the deadline but we noticed several issues that are worthwhile to bring to your attention.

draft-ietf-oauth-pop-key-distribution defines a mechanism that allows the client to talk to the AS to request a PoP access token and associated keying material.

There are two other groups in the IETF where this concept is used.


  *   The guys working on RTCWEB is the first. Misi (Mészáros Mihály) has been helping us to understand their needs. They have defined their own token format, which has been posted on the OAuth group a while ago for review.


  *   The other group is ACE with their work on an OAuth-based profile for IoT.

Where should the parameters needed for PoP key distribution should be defined? Currently, they are defined in two places -- in https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-13 and also in https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03. In particular, the audience and the token_type parameters are defined in both specs.

IMHO it appears that OAuth would be the best place to define the HTTP-based parameters. ACE could define the IoT-based protocols, such as CoAP, MQTT, and alike. Of course, this is subject for discussion, particularly if there is no interest in doing so in the OAuth working group.

There is also a misalignment in terms of the content.. draft-ietf-oauth-pop-key-distribution defined an 'alg' parameter, which does not exist in the draft-ietf-ace-oauth-authz document. The draft-ietf-ace-oauth-authz document does, however, have a profile parameter, which does not exist in draft-ietf-oauth-pop-key-distribution. Some alignment is therefore needed. In the meanwhile the work on OAuth meta has been finalized and could potentially be re-used.

When the work on draft-ietf-oauth-pop-key-distribution was initially started there was only a single, standardized token format, namely the JWT. Hence, it appeared reasonable to use the JWT keying structure for delivering keying material from the AS to the client.

In the meanwhile two other formats have been standardized, namely RFC 7635 and the CWT. For use with those specs it appears less ideal to transport keys from the AS to the client using the JSON/JOSE-based format. It would be more appropriate to use whatever PoP token format is used instead. Currently, this hasn't been considered yet.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.