Change:
characters outside the base64url alphabet, and MUST NOT include base64 padding characters ("="). <del> A client responds to this challenge by constructing a key authorization from the "token" value provided in the challenge and the client's account key.  The client then provisions the key authorization as a resource on the HTTP server for the domain in question. </del> <ins> A client fulfills this challenge by constructing a key authorization from the "token" value provided in the challenge and the client's account key.  The client then provisions the key authorization as a resource on the HTTP server for the domain in question. </ins> The path at which the resource is provisioned is comprised of the fixed prefix "/.well-known/acme-challenge/", followed by the "token" value in the challenge.  The value of the resource MUST be the ASCII representation of the key authorization. <del> The client's response to the validation request indicates its agreement to this challenge by sending the server the key authorization covering the challenge's token and the client's account key. </del> <ins> A client responds with an empty object ({}) to acknowledge that the challenge can be validated by the server. </ins> <del> The key authorization for this challenge.  This value MUST match the token from the challenge and the client's account key. On receiving a response, the server MUST verify that the key authorization in the response matches the "token" value in the challenge and the client's account key.  If they do not match, then the server MUST return an HTTP error in response to the POST request in which the client sent the challenge. </del> <ins> On receiving a response, the server constructs and stores the key authorization from the challenge "token" value and the current client account key. </ins> Given a challenge/response pair, the server verifies the client's control of the domain by verifying that the resource was provisioned

Discussion:
Respond with {} instead of providing keyAuthorization Remove "keyAuthorization" from the challenge object returned by the server. Fixes a potential misguide for clients that enabels a MitM attack. Keep the storing of the keyAuthorization on response to retain the same behavior if an account key roll-over happens before the challenge is validated
I like this change in theory, but it's substantive enough that I'd like to give the mailing list a couple more pokes to see if anyone has further thoughts on it before we land it.
This is not an editorial change, and I think it would require pushing back further on last-call timing. Please bring this up and discuss on the mailing list; WG consensus will be required.
This was brought up on the list Dec 27th and only positive responses were received.
https://ietf-wg-URL From the spec This is not consistent with the example: Which is posting to . I would expect the example to show has . Also, there is no other mention of present in the example payload. Is this a mistake?
The example is correct. The URL for the challenge is , as shown in the response body above the example you cite: (Note the at the end that distinguishes the challenge from the authz URL ) As for the field, it looks like NAME fixed this in
thanks
This PR looks good to me. I think the proposed change makes sense and removes a potential error without sacrificing anything functionality wise. NAME NAME Can you give this a review as well?