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
