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
