Clean up definitions.
In §2 [1] we've got "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of STRING."
But, in the little cow town where I come from anyway, you hash bits/octets not character strings (BTW, "STRING" isn't defined anywhere but it's kind of implied that it's a string of characters).
Should it say something more like "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of the octets of the ASCII [RFC0020] representation of STRING."?
I know it's kind of pedantic but I find it kind of confusing because the code_verifier uses the url and filename safe alphabet, which has me second guessing if SHA256(STRING) actually means a hash of the octet produced by base64url decoding the string.
Maybe it's just me but, when reading the text, I find the transform process to be much more confusing than I think it needs to be. Removing and clarifying some things will help. I hate to suggest this but maybe an example showing the computation steps on both ends would be helpful?
Also "UTF8(STRING)" and "ASCII(STRING)" notations are defined in §2 but not used anywhere.
And §2 also says, "BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, per Section 3, producing a UTF-8 sequence of octets." But what is a UTF-8 sequence of octets? Isn't it just a sequence octets? The [RFC3629] reference, I think, could be removed.
[1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-2
Comments (8)
-
reporter -
reporter re
#32remove un needed UTF8(STRING) definition, and define STRING for ASCII(STRING)→ <<cset f43e06cd47f1>>
-
repo owner We do not use ASCII() either in the spec. So, we should probably drop it.
In exchange, we should add the following:
STRING denotes a sequence of zero or more ASCII [RFC0020] characters. OCTETS denotes a sequence of zero or more octets.
Also, change SHA256(STRING) to:
SHA256(OCTETS) denotes a SHA2 256bit hash [RFC6234] of OCTETS.
-
repo owner - changed status to open
-
repo owner re
#32fixed definitions→ <<cset f4720e12eacd>>
-
reporter re
#32added OCTET(STRING) to make clear that it is the byte array that is being hashed→ <<cset 5c9461e0efef>>
-
reporter re
#32added ASCII(STRING) to make clear that it is the byte array that is being hashed→ <<cset af9ce76988cd>>
-
reporter - changed status to resolved
resolved by af9ce76988cd
- Log in to comment
re
#32remove un needed utf8 reference from BASE64URL-DECODE(STRING) def→ <<cset 5cbd653210f1>>