Hello, Section 7.5.1 of RFC 8555 states the client sends an empty JSON body POST request to the challenge URL to confirm it's ready for validation. This seems, perhaps, overly restrictive, and certainly inefficient for authorization types that are able to produce a valid challenge response at the same time the challenge is accepted, such as the case with a permanent-identifier from a TPM, HSM or other device with attestation capabilities.
You can see this thread for more context: jeremyhahn/go-trusted-platform#2 <https://github.com/jeremyhahn/go-trusted-platform/issues/2> Another issue I encountered worth mentioning (but not as important to me): The base64 encoding scheme in RFC 8555 seems incompatible with the JOSE standard - more specifically, the issue arises because the ACME RFC 8555 expects only the entire protected, payload, and signature fields to be base64url-encoded in the final JOSE object—not each individual element inside them. However, in typical JOSE implementations, each part, like the protected header, is often base64url-encoded before being embedded in the JOSE object. Therefore, ACME expects base64url encoding only on the outermost components, while traditional JOSE implementations may encode internal components as well, causing a mismatch. This mismatch is inconvenient in modern applications based on JOSE and leads to having to maintain two different libraries for serialization and signing. Feedback? Thanks
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
