-----Original Message-----
From: Ludwig Seitz <[email protected]>
Sent: Monday, November 18, 2019 10:15 AM
To: Jim Schaad <[email protected]>;
[email protected]
Cc: [email protected]
Subject: Re: Mail regarding draft-tiloca-ace-revoked-token-notification-00
On 17/11/2019 06:24, Jim Schaad wrote:
> 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.
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?
[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
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
