Hi Olaf, Steffi,

My turn to apologize for the late reply :) I went through the comment again and 
I believe I must have misread something. I am ok with the current text, or the 
previous one as well, if you'd rather not add this sentence.

I do have one additional comment, which came out while looking this over again 
- about the following text:

   correct public key in the DTLS handshake.  If the authorization
   server has specified a "cnf" field in the access token response, the
   client MUST use this key.  Otherwise, the client MUST use the public

The access token is opaque to the client (as defined the ace framework), so the 
client is not necessarily able to read and extract the key it is supposed to 
use from it. If I am not mistaken, the correct way for the AS to tell the 
client what key to use would be to use the "cnf" field defined in Section 3.2 
of oauth-params.

Francesca

On 27/05/2021, 13:25, "Olaf Bergmann" <[email protected]> wrote:

    Hi Francesca,

    Did you have chance to take another look at comment #3 of your review
    (see below)?

    Grüße
    Olaf


    On 2021-05-11, Stefanie Gerdes <[email protected]> wrote:

    >
    > On 3/24/21 4:49 PM, Francesca Palombini via Datatracker wrote:
    >> 
    >> ----------------------------------------------------------------------
    >> COMMENT:
    >> ----------------------------------------------------------------------
    >> 
    >> 3. ------
    >> 
    >>    raw public keys, it needs to determine which key to use.  The
    >>    authorization server can help with this decision by including a "cnf"
    >>    parameter in the access token that is associated with this
    >>    communication.  In this case, the resource server MUST use the
    >> 
    >> FP: The example in Figure 4 show how the whole RPK of the client can be
    >> included in the access_token, so maybe this paragraph should cover that 
case,
    >> or the example changed.
    >
    > I am not quite sure if I understand your comment. In Figure 4, the
    > contents of the access token is omitted for brevity. The response
    > contains access information for the client with the server's RPK in
    > the rs_cnf parameter. This is required by the client to authenticate
    > its peer during the DTLS handshake. We changed the example paragraph
    > so that it now explains the use of the rs_cnf parameter. Does that
    > make it more clear?

    The new text we have included reads:

    "The response comprises access information for the client that contains
    the server's public key in the rs_cnf parameter."

_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace

Reply via email to