But, while it may be clear to you, what I'm saying here is that it's not
clear to a reader/implementer.
Somehow the conversion from a character string to an octet string needs to
be clearly and unambiguously stated. It doesn't have to be the text I
suggested but it's not sufficient as it is now.
OK try that one.
On Jan 30, 2015, at 5:15 PM, Brian Campbell bcampb...@pingidentity.com
wrote:
I agree with Mike here. Though PKCE only needs the ASCII(STRING) one.
On Fri, Jan 30, 2015 at 12:38 PM, Mike Jones michael.jo...@microsoft.com
mailto:michael.jo...@microsoft.com wrote:
https://bitbucket.org/Nat/oauth-spop/commits/af9ce76988cd32b334e21c71289721a3bf1c4ff1
looks good to me. Thanks John.
On Fri, Jan 30, 2015 at 1:47 PM, John Bradley ve7...@ve7jtb.com wrote:
OK try that one.
On Jan 30, 2015, at 5:15 PM, Brian Campbell bcampb...@pingidentity.com
wrote:
I agree
Ok I will push out draft 7 to the doc tracker later today.
Sent from my iPhone
On Jan 30, 2015, at 6:06 PM, Brian Campbell bcampb...@pingidentity.com
wrote:
https://bitbucket.org/Nat/oauth-spop/commits/af9ce76988cd32b334e21c71289721a3bf1c4ff1
looks good to me. Thanks John.
On Fri,
Hello,
I have uploaded a new revision of the Audit draft.
It discusses an audit feature in OAuth 2.0 environments, namely,
- the parameters that are valuable for audit purposes,
- the audit log examination and querying,
- audit records privacy and security.
As it is currently stated in the
Have a look at the latest version I added OCTETS(STRING) to show the
conversion. ASCII(STRING) seemed more confusing by drawing character encoding
back in.
I was tempted to call it a octet array without the terminating NULL of STRING
but didn’t want to introduce array.
Let me know what you
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : Proof Key for Code Exchange by OAuth Public Clients
Authors : Nat Sakimura
I do not think we need ASCII(). It is quite clear without it, I suppose.
In 4.1, I would rather do like:
code_verifier = high entropy cryptographic random
octet sequence using the url and filename safe Alphabet [A-Z] / [a-z]
/ [0-9] / - / _ from Sec 5 of RFC 4648 [RFC4648], with length
That's definitely an improvement (to me anyway).
Checking that the rest of the document uses those notations appropriately,
I think, yields a few other changes. And probably begs for the
ASCII(STRING) denotes the octets of the ASCII representation of STRING
notation/function, or something like
