My 2cent as individual contributor:
I like the use of the BASE64URL notation without apostrophes better,
because as you said, it could be pefect javascript (considering
javascript as the ideal template language for JSON).
Then again, we did introduce the pseudovalue "base64encodedvalue=="
in rfc8366 and it's been used in various other RFC including non-anima
RFCs (such as rfc8572), so it seems nobody rejected that notion in
various IETF standard track review, so if we would use the notation with
apostrophes i think that would be inline with that prior art.
Pick your preferred poison...
Cheers
Toerless
On Tue, Jul 18, 2023 at 11:38:02AM -0400, Michael Richardson wrote:
>
> In the JWS I-D, we have some JSON that is an example.
> And the content within is BASE64URL encoded.
> We could, I think, describe this in CDDL, but we aren't trying to be
> authoritative. (It's a JOSE example)
>
> We are struggling with quoting. We could write:
>
> "payload": "BASE64URL(ietf-voucher:voucher)",
>
> which would make it valid JSON, with the literal contents.
> Or we could write:
>
> "payload": BASE64URL(ietf-voucher:voucher),
>
> which sorta makes it valid Javascript, assuming such a function existed.
>
>
> here is an example with both variations:
>
> {
> "payload": BASE64URL(ietf-voucher:voucher),
> "signatures": [
> {
> "protected": "BASE64URL(UTF8(JWS Protected Header))",
> "signature": "base64encodedvalue=="
> }
> ]
> }
>
>
>
> --
> Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
