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
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
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
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
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 zero or
Barry Leiba has entered the following ballot position for
draft-ietf-oauth-spop-14: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
