Re: [OAUTH-WG] DPoP - token hash - ASCII encoding question

2022-12-27 Thread devi prasad
Thank you, Brian, for the reference: A.12 - access token syntax (RFC 6749).
That really helped.

On Tue, Dec 27, 2022 at 10:32 PM Brian Campbell 
wrote:

> No bit flipping is needed. It is just meant to say that the bytes of the
> ASCII representation of the access token value are the input to the hash
> function.  The access token value itself should only be made up of
> printable ASCII characters
> https://www.rfc-editor.org/rfc/rfc6749#appendix-A.12 BTW.
>
> The ath value in
> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-11.html#figure-13
> is the hash of the access token from
> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-11.html#figure-12
> if you want to check your work.
>
>
>
>
> On Mon, Dec 26, 2022 at 2:10 AM devi prasad  wrote:
>
>> DPoP mentions the **ASCII encoding** of a token value. This appears
>> twice in the spec:
>>
>> *section 4.2. DPoP Proof JWT Syntax*...
>> ath: hash of the access token. The value MUST be the result of a
>> base64url encoding (as defined in Section 2 of [RFC7515]) the SHA-256 [SHS]
>> hash of the ASCII encoding of the associated access token's value.
>> and
>> *section 12.7. JSON Web Token Claims Registration*
>> ...
>> Access token hash:
>> ...
>> Claim Description: The base64url encoded SHA-256 hash of the ASCII
>> encoding of the associated access token's value.
>> I'm trying to develop a bunch of test cases, and would like to know the
>> meaning more precisely.
>>
>> Does ASCII encoding mean that the algorithm should
>> (1) treat the access token's value as an array(or a sequence) of unsigned
>> bytes, and
>> (2) clear the most-significant-bit (MSB) of each byte in the array.
>> (3) calculate SHA-256 of the byte array obtained in step 2.
>> (4) calculate the base64url encoding of the bytes obtained in step 3.
>>
>> Is this the correct interpretation? Especially the step 2 that clears the
>> MSB of each byte?
>> (I'm not assuming tokens to be JWTs; intend to support proprietary token
>> representations and opaque tokens).
>>
>> Thank you!
>> Devi Prasad
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


Re: [OAUTH-WG] DPoP - token hash - ASCII encoding question

2022-12-27 Thread Brian Campbell
No bit flipping is needed. It is just meant to say that the bytes of the
ASCII representation of the access token value are the input to the hash
function.  The access token value itself should only be made up of
printable ASCII characters
https://www.rfc-editor.org/rfc/rfc6749#appendix-A.12 BTW.

The ath value in
https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-11.html#figure-13 is
the hash of the access token from
https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-11.html#figure-12 if
you want to check your work.




On Mon, Dec 26, 2022 at 2:10 AM devi prasad  wrote:

> DPoP mentions the **ASCII encoding** of a token value. This appears twice
> in the spec:
>
> *section 4.2. DPoP Proof JWT Syntax*...
> ath: hash of the access token. The value MUST be the result of a base64url
> encoding (as defined in Section 2 of [RFC7515]) the SHA-256 [SHS] hash of
> the ASCII encoding of the associated access token's value.
> and
> *section 12.7. JSON Web Token Claims Registration*
> ...
> Access token hash:
> ...
> Claim Description: The base64url encoded SHA-256 hash of the ASCII
> encoding of the associated access token's value.
> I'm trying to develop a bunch of test cases, and would like to know the
> meaning more precisely.
>
> Does ASCII encoding mean that the algorithm should
> (1) treat the access token's value as an array(or a sequence) of unsigned
> bytes, and
> (2) clear the most-significant-bit (MSB) of each byte in the array.
> (3) calculate SHA-256 of the byte array obtained in step 2.
> (4) calculate the base64url encoding of the bytes obtained in step 3.
>
> Is this the correct interpretation? Especially the step 2 that clears the
> MSB of each byte?
> (I'm not assuming tokens to be JWTs; intend to support proprietary token
> representations and opaque tokens).
>
> Thank you!
> Devi Prasad
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth