Re: [Ace] WGLC for draft-ietf-ace-oauth-params
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 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-oauth-params
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 On Behalf Of Jim Schaad Sent: Monday, October 8, 2018 2:35 PM To: ace@ietf.org 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 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 ___ Ace mailing list Ace@ietf.org<mailto:Ace@ietf.org> https://www.ietf.org/mailman/listinfo/ace ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-oauth-params
On 22/10/2018 21:09, Jim Schaad wrote:
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?
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.
* We need to have a OAuth CBOR integer mapping registry - the items in
section 6 need to be registered into that registry.
That was an oversight. Issue created.
* Review - is the 'cnf' parameter in section 3.2 ok with the OAuth group or
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?").
* Check that cnf in 4.1 is going to be ok with
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
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-oauth-params
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 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
