Hi all, I read through draft-ietf-ace-oauth-params-00 and have a few comments.
1) I believe the document should explain in more detail about how it fits into the rest of the OAuth PoP token work. The story essentially is that we have the HTTP-based transport in the OAuth WG and we have the CoAP-based transport in ACE. draft-ietf-ace-oauth-params-00 is about registering the necessary parameters for use with CoAP only. Neither the abstract nor the intro says this. 2) 'req_aud' parameter At the last IETF OAuth meeting in Montreal we agreed to adopt a new document, called resource indicators, and it can be found here: https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01 I believe the parameter name and semantics defined in draft-ietf-oauth-resource-indicators-01 should match what is defined in draft-ietf-ace-oauth-params-00. The name of the parameter in draft-ietf-oauth-resource-indicators-01 is 'resource' and it is defined as resource Indicates the location of the target service or resource where access is being requested. Its value MUST be an absolute URI, as specified by Section 4.3 of [RFC3986], which MAY include a query component but MUST NOT include a fragment component. Multiple "resource" parameters MAY be used to indicate that the requested token is intended to be used at multiple resources. In a nutshell I believe you should do the following: a) rename the parameter to 'resource' to get it inline with draft-ietf-oauth-resource-indicators-01 b) use the same semantics as in draft-ietf-oauth-resource-indicators-01 c) find out what the encoding considerations are when using CoAP 3) 'req_cnf' parameter Changing the name of the parameter name from the previous 'cnf' is good and that was also requested at the last IETF due to the potential confusion with the 'cnf' claim name. However, I believe the semantics is different to the semantics defined in draft-ietf-oauth-pop-key-distribution. Unless I misunderstand but the relevant text regarding the req_cnf parameter content is this: o "req_cnf" in the token request C -> AS, OPTIONAL to indicate the client's raw public key, or the key-identifier of a previously established key between C and RS that the client wishes to use for proof-of-possession of the access token. For example, in draft-ietf-oauth-pop-key-distribution there is no key identifier passed from the client to the server when making the request for a PoP token. Instead, the server just mints one (along with the symmetric key) and sends it to the client. Ciao Hannes PS: Why was a standalone document written instead of leaving the parameters in the ACE-OAuth framework spec? I guess there are reasons (which I may have missed). 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.
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
