That solution is fine with me. From RFC7662’s perspective, JSON is the
canonical form, and any other representation should be able to be translated
from that. While not mentioned in 7662, I see no problem with other
representations having special optimizations for any given field, and so this
HI,
"My proposed fix for this would be to amend the descriptions of these
two parameters in 5.9.2, specifying that their JSON representation is a
text string containing the Base64url encoding of the original byte
string payload."
exactly the same fix we did for json and cbor voucher-request
Hello ACE (Cc to OAuth designated expert Justin),
The progress of draft-ietf-ace-oauth-authz is currently blocked due to an issue
that has come to light in the IANA review process, and I'd like to solicit the
feedback of the WG to determine how to go forward.
The issue is related to parameters
