> In JWS we used ASCII(string) to indicate that the output is a sequence of
> octets, strings are not necessarily 8 characters bits and may have null
> termination etc.
>
> However as Brian states other changes may have removed the need for that.
>
> I admit saying "where STRING is a sequence of ze
I have a draft with Barry’s edits less the removal of ASCII(string) ready to go.
In JWS we used ASCII(string) to indicate that the output is a sequence of
octets, strings are not necessarily 8 characters bits and may have null
termination etc.
However as Brian states other changes may have remo
Thanks for your responses on these comments.
I can approve an updated draft to make this change and the one for IANA if
that is the easiest path. The other option is to write this all up in an
RFC editor note and I can send that with the approval. Making the direct
updates may be simpler to avoi
Regarding the comment on Section 2, I had originally argued for the
inclusion of ASCII(xxx) as I felt it was important to avoid potential
ambiguity that was in the draft at the time (it wasn't 100% clear to me at
the time if the code_verifier was to be base64url decoded as input into the
hash or if
Thanks Barry,
These are the issues that I wanted to discuss with John before making
change.
-- Section 6.2 -- John has partly addressed your IANA comment already. I
needed
to check if there was any reason for just doing partly.
-- Section 7.2 -- is probably just my oversight. I will deal with i
