Confusion around section 7.5.1

[unixcharles]

https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html#rfc.section.7.5.1

From the spec

The client sends these updates back to the server in the form of a JSON object with contents as specified by the challenge type, carried in a POST request to the challenge URL (not authorization URL) once it is ready for the server to attempt validation.

This is not consistent with the example:

POST /acme/authz/1234/0 HTTP/1.1
Host: example.com
Content-Type: application/jose+json

{
  "protected": base64url({
    "alg": "ES256",
    "kid": "https://example.com/acme/acct/1",
    "nonce": "Q_s3MWoqT05TrdkM2MTDcw",
    "url": "https://example.com/acme/authz/1234/0"
  }),
  "payload": base64url({
    "keyAuthorization": "IlirfxKKXA...vb29HhjjLPSggwiE"
  }),
  "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"
}

Which is posting to /acme/authz/1234/0. I would expect the example to show has /acme/challenges/1234/0.

Also, there is no other mention of keyAuthorization present in the example payload. Is this a mistake?

[bifurcation]

The example is correct. The URL for the challenge is /acme/authz/1234/0, as shown in the response body above the example you cite:

HTTP/1.1 200 OK
Content-Type: application/json
Link: <https://example.com/acme/some-directory>;rel="index"

{
  "status": "pending",
  "expires": "2018-03-03T14:09:00Z",

  "identifier": {
    "type": "dns",
    "value": "example.org"
  },

  "challenges": [
    {
      "type": "http-01",
      "url": "https://example.com/acme/authz/1234/0",
      "token": "DGyRejmCefe7v4NfDGDKfA"
    },
    {
      "type": "dns-01",
      "url": "https://example.com/acme/authz/1234/2",
      "token": "DGyRejmCefe7v4NfDGDKfA"
    }
  ]
}

(Note the /0 at the end that distinguishes the challenge from the authz URL /acme/authz/1234)

As for the keyAuthorization field, it looks like @sophie-h fixed this in #375

[unixcharles]

thanks