I'm tempted to say that the "" / null ambiguity is an interop problem for
JOSE, not for us. But nonetheless, it's a problem.
I'm still uncomfortable with {}, though, because it risks colliding with
other POST uses. What would you guys think about one of these explicit
markers:
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
Personally, I find (1) a little more explicit. It's a little more bloat
because of the URN cruft, but (1) it doesn't make sense to register a
generic, unprefixed parameter, and (2) checking for "{}" is easier than
checking for "no other fields".
--Richard
On Tue, Sep 4, 2018 at 3:17 PM Logan Widick <logan.wid...@gmail.com> wrote:
> I like using {} for the POST-as-GET payload as well.
>
> Sincerely,
>
> Logan Widick
>
> On Tue, Sep 4, 2018, 12:26 Jacob Hoffman-Andrews <j...@eff.org> wrote:
>
>> New day, new thread for a specific issue I'd like to nail down quickly.
>>
>> > ISSUE 2: How should we signal that POST-as-GET request is different
>> > from other POST requests?
>> >
>> > The current PR signals this by sending a JWS with an empty
>> > (zero-octet) payload, instead of a JSON object. Jacob and Daniel
>> > suggested that we should instead use the payload being an empty JSON
>> > object as the signal. An earlier draft PR used a field in the
>> > protected header.
>>
>> In short, this question is about whether POST-as-GETs should have:
>>
>> "payload": ""
>>
>> or
>>
>> "payload": "{}"
>>
>>
>> When implementing the first one (empty payload), Daniel and I each
>> separately implemented a different bug that would have also accepted:
>>
>> "payload": null
>>
>> This may be quirk of Go's handling of byte arrays, but it may turn out
>> to be a common pattern in JSON libraries. The downside, if a server
>> implementer landed a bug like that, would be that clients might get away
>> with generating the invalid "null" form, leading to interoperability
>> problems.
>>
>> There's also potential for client bugs that produce an empty payload
>> simply due to an uninitialized field, rather than due to a POST-as-GET.
>> This would produce confusing errors relating to GETs rather than a
>> clearer "malformed input" error.
>>
>> Lastly, many clients already implement the "{}" form as a way to GET an
>> account, so expanding the use of "{}" minimizes disruption.
>>
>> My preference is still for "{}" over "", but I am also willing to be
>> convinced in the interests of landing this change speedily and keeping
>> forward momentum.
>>
>> _______________________________________________
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
