Subject: [Ace] Mail regarding draft-tiloca-ace-revoked-token-notification-00

From: Jim Schaad <[email-masked]>
Date: Sun, 17 Nov 2019 13:24:39 +0800

Small comment.

If you use CBOR to transport a token, then it is easy to hash it because it
is always going to be the raw bytes.  If you use JSON to transport a token
then it will be the raw bytes for a JWT, but it would be a base64url encoded
value for a CWT.  This means that the hash might not get the correct answer.

Jim

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 18 Nov 2019 03:14:44 +0100

On 17/11/2019 06:24, Jim Schaad wrote:
> If you use JSON to transport a token

The problem here is that the client wouldn't know the format of the 
token and therefore not be able to retrieve the correct binary 
representation (I'm assuming both the RS and the AS would know).

I think the best solution is to define that the data getting hashed is 
to be the binary representation of what is in the 'access_token' 
parameter of the access token response, since that is what everyone (AS, 
Client, RS) sees.

For a CBOR transport that would just be the byte-string value of 
'access_token' as is, while for JSON transport this be the binary 
representation of the String value of 'access_token', which would of 
course depend on the charset.

Side-note: Do we want/need to cater for such a weird corner-case? Who in 
their right mind would use JSON in a CoAP message?

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

---

From: Jim Schaad <[email-masked]>
Date: Mon, 18 Nov 2019 10:22:55 +0800

-----Original Message-----
From: Ludwig Seitz <[email-masked]> 
Sent: Monday, November 18, 2019 10:15 AM
To: Jim Schaad <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: Mail regarding draft-tiloca-ace-revoked-token-notification-00

[JLS] You have the corner-case above backwards.  The question is who would be using a CWT (or binary token) in a JSON message.

I am currently using JWT tokens in a CoAP message right now for my MQTT work because it was an easier starting point than to get an HTTP server up and running.

Jim

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51