On 09/05/2018 08:33 AM, Richard Barnes wrote:
1. A field in the protected header ("urn:ietf:params:acme:get": true)
with a requirement that the payload be "{}"
2. A field in the payload ({"get": true}) a requirement that if that
field be there, then there are no other fields present
I dislike both of these options as adding complexity. My preference
order is:
1) "{}"
2) ""
99) "urn:ietf:params:acme:get"
> I'm still uncomfortable with {}, though, because it risks colliding
with other POST uses.
The only current use it conflicts with is POSTing to challenges to
trigger their validation. We can fix that two ways:
- Define challenges as non-pollable: Poll authorizations instead,
since they contain the challenges. This was something I'd proposed
previously, in the spirit of "there should just be one way to do
things." Right now, some clients poll authorizations and some poll
challenges. There's no benefit to one way or the other, it's just a
random implementer choice that sometimes exposes different code paths.
- Define multiple POSTs to challenges as idempotent. That is, the
first time you POST a "{}" body to a challenge it triggers validation,
and subsequently it acts as a GET.
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
