Subject: [Ace] Parameter abbreviation number ranges for draft-ietf-ace-oauth-authz

From: Ludwig Seitz <[email-masked]>
Date: Mon, 27 Aug 2018 09:52:03 +0200

Hello group,

at IETF 102 there was a discussion about the numerical abbreviations we 
introduced for both OAuth parameter names and access token claim names.

I have generated a proposal that makes better use of the number space, 
but I'd like the OAuth specialists to have a look at it and see if I 
pushed any important (= frequently used) OAuth parameter into the two 
byte number range.

Background:

CBOR integers have a very compact representation (1 byte) for numbers 
from 0-23, from 24-255 (which is all we will ever need ;-) ) they use 2 
bytes. Thus we'd like to use abbreviations in the first number range for 
parameters/claims that are frequently used.

My proposal follow below, please feel free to comment.

/Ludwig
================================================================================

Existing claim name abbreviations from RFC 8392 (CWT) :
  iss  1
  sub  2
  aud  3
  exp  4
  nbf  5
  iat  6
  cti  7

New claim name abbreviation introduced by 
draft-ietf-ace-cwt-proof-of-possession:

  cnf  8

New claims introduced by draft-ietf-ace-oauth-authz (with proposed 
abbreviations):

  scope 9
  profile 10
  rs_cnf 11

Token endpoint parameters from RFC 6749 (OAuth 2.0) (with proposed 
abbreviations):

scope 9
error 12
grant_type 13
access_token 14
token_type 15

client_id      24
client_secret  25
response_type  26
state 27
redirect_uri 28
error_description 29
error_uri 30
code 31
expires_in 32
username 33
password 34
refresh_token 35

New token endpoint parameters introduced by draft-ietf-ace-oauth-authz
(with proposed abbreviations):

req_aud 16
req_cnf 17
used_cnf 18
rs_cnf 19

(Note that req_* and used_cnf are not yet in the draft, but we came to 
the conclusion we will need them after the OAuth session at IETF 102. 
They will be in the next update)

Introspection endpoint paramenters from RFC  (OAuth 2.0 introspection)
(with proposed abbreviations):

iss 1
sub 2
aud 3
exp 4
iat 6
nbf 5
scope  9
token_type 15
active 20
client_id 24
username 33
jti (no abbreviation, we have cti)

New introspection endpoint parameters introduced by 
draft-ietf-ace-oauth-authz:

cnf 8
rs_cnf   19
profile  10

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

---

From: Jim Schaad <[email-masked]>
Date: Mon, 27 Aug 2018 09:19:51 -0700

> -----Original Message-----
> From: Ace <[email-masked]> On Behalf Of Ludwig Seitz
> Sent: Monday, August 27, 2018 12:52 AM
> To: [email-masked]
> Subject: [Ace] Parameter abbreviation number ranges for
draft-ietf-ace-oauth-
> authz
> I have generated a proposal that makes better use of the number space, but
I'd
> like the OAuth specialists to have a look at it and see if I pushed any
important
> (= frequently used) OAuth parameter into the two byte number range.
> 
> 
> Background:
> 
> CBOR integers have a very compact representation (1 byte) for numbers from
> 0-23, from 24-255 (which is all we will ever need ;-) ) they use 2 bytes.
Thus
> we'd like to use abbreviations in the first number range for
parameters/claims
> that are frequently used.
> 

[JLS] I would be willing to push error_description and error_uri up into the
two byte range I don't think they fall into the frequently used category in
a working system.  I don't know that we need to keep client_id,
client_secret, username and password in the low range at this time.   Do we
really think that we are going to be using this on small devices?

> New token endpoint parameters introduced by draft-ietf-ace-oauth-authz
(with
> proposed abbreviations):
> 
> req_aud 16
> req_cnf 17
> used_cnf 18
> rs_cnf 19
> 
> (Note that req_* and used_cnf are not yet in the draft, but we came to the
> conclusion we will need them after the OAuth session at IETF 102.
(with
> proposed abbreviations):
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Samuel Erdtman <[email-masked]>
Date: Mon, 27 Aug 2018 18:39:02 +0200

+1 on pushing up error_description and error_uri

I think client_id might be worth keeping low since it is often used even
when in combination with client_secret. See OAuth Mtls as an example.
On Mon, 27 Aug 2018 at 18:20, Jim Schaad <[email-masked]> wrote:

> but
> from
> the

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 28 Aug 2018 08:39:43 +0200

On 2018-08-27 18:19, Jim Schaad wrote:
>~snip~

Good we agree an that then. Actually according to my understanding of 
CBOR integers they already are in the two byte category (see quoted part 
above the ~snip~).

/Ludwig

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

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 28 Aug 2018 08:44:23 +0200

On 2018-08-27 18:39, Samuel Erdtman wrote:
> On Mon, 27 Aug 2018 at 18:20, Jim Schaad <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 

Note that the 1 byte range is 0-23

Currently in the 1 byte uint range we have 20-23 left unused

We could start assigning negative integer values in the 1 byte range if 
needed.

/Ludwig

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

---

From: Mike Jones <[email-masked]>
Date: Tue, 28 Aug 2018 16:44:36 +0000

Especially in light of the possibility of signed requests along the lines of https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-16, I believe that all the ACE OAuth parameters should be registered as CWT claims.  I'll repeat my request, wearing my designated expert hat, that application-specific values not be requested for registration in the one-byte ranges.  The one-byte values should be saved for claims that are likely to span multiple kinds of applications.

				-- Mike

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Ludwig Seitz
Sent: Monday, August 27, 2018 11:44 PM
To: Samuel Erdtman <[email-masked]>; Jim Schaad <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ace] Parameter abbreviation number ranges for draft-ietf-ace-oauth-authz

On 2018-08-27 18:39, Samuel Erdtman wrote:
> I think client_id might be worth keeping low since it is often used 
> even when in combination with client_secret. See OAuth Mtls as an example.

We could start assigning negative integer values in the 1 byte range if needed.

/Ludwig

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

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 29 Aug 2018 09:04:31 +0200

On 2018-08-28 18:44, Mike Jones wrote:
> Especially in light of the possibility of signed requests along the
> lines of https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-16, I
> believe that all the ACE OAuth parameters should be registered as CWT
> claims.  

Ok.

> I'll repeat my request, wearing my designated expert hat,
> that application-specific values not be requested for registration in
> the one-byte ranges.  The one-byte values should be saved for claims
> that are likely to span multiple kinds of applications.
> 

So what is not generic OAuth 2.0 (+ OAuth introspection) is the following:

cnf
scope
profile
rs_cnf
req_aud
req_cnf
used_cnf

I am aware of your point-of-view on the 'profile' parameter and I 
disagree with it (I feel it is sufficient to make it OPTIONAL).

What are your thoughts about the other parameters (keeping in mind that 
'req_aud', 'req_cnf' and 'used_cnf' are going to replace the use of 
'aud' and 'cnf' in the ACE request/response interactions)?.

Regards,

Ludwig

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

---

From: Jim Schaad <[email-masked]>
Date: Wed, 29 Aug 2018 09:32:17 -0700

We are doing all of this in response to a draft?  Why can you not fix the
draft and put the OAuth parameters in a sub map so there is no collisions?

Jim

> From: Mike Jones <[email-masked]>
> Sent: Tuesday, August 28, 2018 9:45 AM
> To: Ludwig Seitz <[email-masked]>; Samuel Erdtman <[email-masked]>;
> Jim Schaad <[email-masked]>
> Cc: [email-masked]
> Subject: RE: [Ace] Parameter abbreviation number ranges for
draft-ietf-ace-
> oauth-authz
> 
> Especially in light of the possibility of signed requests along the lines
of
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-16, I believe that all
the ACE
> OAuth parameters should be registered as CWT claims.  I'll repeat my
request,
> wearing my designated expert hat, that application-specific values not be
> requested for registration in the one-byte ranges.  The one-byte values
should
> be saved for claims that are likely to span multiple kinds of
applications.
> Subject: Re: [Ace] Parameter abbreviation number ranges for
draft-ietf-ace-
> oauth-authz
needed.