Subject: [Ace] CoAP option for Access token

From: Samuel Erdtman <[email-masked]>
Date: Sat, 30 Jan 2016 22:48:24 +0100

Hi,

Working on the draft-ietf-ace-oauth-authz draft I see the need for a CoAP
Option to send access token in. This option can be used when token is
smaller then 255 bytes. Then it comes down to the trade-of between sending
the access token once to the authorization information resource at the RS
and sending it in each request as this option.

Can we agree that we need this option?
Should we call it Access-Token or is that to specific?

Best Regards
//Samuel

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 1 Feb 2016 08:52:09 +0100

On 01/30/2016 10:48 PM, Samuel Erdtman wrote:
> Hi,
>
> Working on the draft-ietf-ace-oauth-authz draft I see the need for a
> CoAP Option to send access token in. This option can be used when token
> is smaller then 255 bytes. Then it comes down to the trade-of between
> sending the access token once to the authorization information resource
> at the RS and sending it in each request as this option.
>

Wouldn't it still be possible for the RS to save a token sent in an option?
Would it then not be possible for the client to remember that it already 
sent this token in a previous request (and that it is still valid)?
Would the client then not be able to omit it from further requests 
(until it is no longer valid)?

The real trade-off is a bit more complex:

1.) You can use blockwise to fragment large payloads

2.) If your token is large you'd therefore rather send it as payload

3a.) Not all requests have payload (GET, DELTETE)

3b.) The application needs to know that the payload contains a token

4a.) Either you mix the token and the real application payload and as a 
benefit you can send both together in one request (provided the type 
supports payload) ...

4b.) ... or you separate the token-payload from the real application 
payload (which may not exist) and send two messages, where the token 
message needs to go to some resource that understands that this is a token.

Voila! This is the trade-off

tl;dr: Trade-off is: Mix token and payload and have the app-logic deal 
with it, or separate them and create a resource that processes tokens.

> Can we agree that we need this option?

I agree.

> Should we call it Access-Token or is that to specific?

Access-Token sounds indeed reasonable.

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70 349 9251
http://www.sics.se