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 <oauth-boun...@ietf.org> On Behalf Of Hannes Tschofenig
Sent: Tuesday, July 3, 2018 12:46 PM
To: oauth@ietf.org
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.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to