On 23/10/2018 21:09, Hannes Tschofenig wrote:
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.
Ok I can update the introduction.
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.
Actually at the moment it is about registering necessary parameters for
both HTTP and CoAP and whatever other transport you can want, since when
I wrote it draft-ietf-oauth-pop-key-distribution was dormant.
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'll have a look at that draft. How close is it to WGLC?
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.
Weird, because in the RFC7800 there is a cnf claim with just a key-id. I
thought that you would want to be able to do something similar when
requesting a specific, previously known key.
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).
The idea was that OAuth could obsolete that document when they sort the
pop stuff out, without obsoleting the ACE framework. Thus a different
standalone document.
/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
