Subject: [Ace] WGLC for draft-ietf-ace-oauth-params

From: Jim Schaad <[email-masked]>
Date: Mon, 8 Oct 2018 14:34:40 -0700

The chairs believe that the set of documents dealing with the OAuth
framework for constrained environments is nearing the point that we should
be able to advance it to the IESG for publication.   We therefore want to
have a full list of issues that need to be dealt with at the Bangkok
meeting.

This starts a 2 week WGLC for draft-ietf-ace-oauth-params

We know that the following issues are outstanding:

draft-ietf-ace-oauth-params:
*  No current known issues

Jim & Roman

---

From: Jim Schaad <[email-masked]>
Date: Mon, 22 Oct 2018 12:09:25 -0700

Here are my WGLC comments:

*  I am not sure that I understand what the protocol flow is when JAR is
being used.  Is there a potential case where a JWT would be used as the
structure of an OAuth response?  If so then is there a problem with defining
cnf in section 4.1?

* We need to have a OAuth CBOR integer mapping registry - the items in
section 6 need to be registered into that registry.

* Review - is the 'cnf' parameter in section 3.2 ok with the OAuth group or
does it need to be renamed as well?

* Check that cnf in 4.1 is going to be ok with
draft-ietf-oauth-jwt-introspection-response

Jim

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 23 Oct 2018 09:49:58 +0200

> structure of an OAuth response?  If so then is there a problem with defining

I wouldn't think so, all the other possible parameters in the 
introspection response are defined to be the claims of the token in RFC 
7662, cnf is a claim of the token, so I don't see why it shouldn't go 
unchanged into the introspection response.
> section 6 need to be registered into that registry.

That was an oversight. Issue created.

> does it need to be renamed as well?

I don't see how this could collide with another meaning. The AS is 
responding with the token and additional information about the token 
here. This parameter was called 'key' in 
draft-ietf-oauth-pop-key-distribution, which felt more phrone to 
misunderstandings to me ("what key?").

> draft-ietf-oauth-jwt-introspection-response

If I understood it correctly draft only proposes to replace the whole 
introspection response with a JWT. I don't see why this shouldn't work 
with a CWT as well. No additional data but the JWT/CWT would be sent in 
the introspection response, so there should not be any issue with the 
cnf claim here.

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

---

From: Mike Jones <[email-masked]>
Date: Wed, 24 Oct 2018 20:49:32 +0000

3.1, 3.2, and 4.1, parameter definitions: None of these parameter definitions specify the syntax of the parameters defined, making understanding these quite confusing.  Yes, this is talked about later in the doc but there are not even forward references to where the definitions are completed in most cases.  Please fully specify the parameters when they are defined.

3.1 req_aud: Doesn't this duplicate the "resource" parameter defined by https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01?  If so, please delete this parameter.  If not, say how it is different and why the differences are necessary.

5 cnf in the introspection response: Which token is being referred to by the phrase "bound to the token".  The access token?  The refresh token?  Another kind of token?  Please make this more specific.

6 CBOR Mappings.  The table contains the magic numbers 8, 17, 18, and 19.  >From what space are these numbers being allocated and what registry are they in?  Per my earlier reviews of the ace-authz spec, I believe that the ACE OAuth parameters should all be registered in the CWT Claims registry because of the possibility of them being used in signed requests in a manner analogous to https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17.  The parameters need to be registered to avoid claim number conflicts.

Missing Examples:  The best thing you could do to help developers understand what these values are and how they use them is to add examples, just as was done in RFC 7800.  Please add examples of each of the parameters using the JSON representations of them.  Optionally, also add CBOR examples if you believe that they will convey important information to developers that the JSON example's don't.

                                                          Thank you,

                                                          -- Mike

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Jim Schaad
Sent: Monday, October 8, 2018 2:35 PM
To: [email-masked]
Subject: [Ace] WGLC for draft-ietf-ace-oauth-params

The chairs believe that the set of documents dealing with the OAuth framework for constrained environments is nearing the point that we should

have a full list of issues that need to be dealt with at the Bangkok meeting.

Jim & Roman

_______________________________________________

Ace mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/ace

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 29 Oct 2018 15:44:59 +0100

On 24/10/2018 22:49, Mike Jones wrote:
> 3.1, 3.2, and 4.1, parameter definitions: None of these parameter 
> definitions specify the syntax of the parameters defined, making 
> understanding these quite confusing.  Yes, this is talked about later in 
> the doc but there are not even forward references to where the 
> definitions are completed in most cases.  Please fully specify the 
> parameters when they are defined.
> 
> 3.1 req_aud: Doesn’t this duplicate the “resource” parameter defined by 
> https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01?  If 
> so, please delete this parameter.  If not, say how it is different and 
> why the differences are necessary.
> 
> 5 cnf in the introspection response: Which token is being referred to by 
> the phrase “bound to the token”.  The access token?  The refresh token?  
> Another kind of token?  Please make this more specific.
> 
> 6 CBOR Mappings.  The table contains the magic numbers 8, 17, 18, and 
> 19.  From what space are these numbers being allocated and what registry 
> are they in?  Per my earlier reviews of the ace-authz spec, I believe 
> that the ACE OAuth parameters should all be registered in the CWT Claims 
> registry because of the possibility of them being used in signed 
> requests in a manner analogous to 
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17.  The parameters 
> need to be registered to avoid claim number conflicts.
> 
> Missing Examples:  The best thing you could do to help developers 
> understand what these values are and how they use them is to add 
> examples, just as was done in RFC 7800.  Please add examples of each of 
> the parameters using the JSON representations of them.  Optionally, also 
> add CBOR examples if you believe that they will convey important 
> information to developers that the JSON example’s don’t.
> 
>                                                            Thank you,
> 
>                                                            -- Mike

Hello Mike,

thank you for your review. I've added issues to the tracker here:
https://github.com/ace-wg/ace-oauth-params
and will address your comments.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51