Clean up definitions.

Issue #32 resolved
John Bradley created an issue

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)

  1. Nat Sakimura 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.
    
  2. Log in to comment