Using the same notation, I'm:
1) ""
2) "urn:ietf:params:acme:get"
99) "{}"
The problem with "{}" is not just what it conflicts with in the current
doc, it's that it constrains everything one might do in the future. Same
with any other payload-only option (including {"get": true}) with valid
JSON payload. So your options are (1) do something in the protected header
or (2) have the payload be something non-JSON.
If you want something payload-only that is not empty, that seems doable as
well. We could require the payload to be the two-octet string 0x1844,
which conveniently base64url-encodes to "GET" :)
On Wed, Sep 5, 2018 at 1:17 PM Jacob Hoffman-Andrews <j...@eff.org> wrote:
> 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
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
