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

[Ludwig Seitz]

On 2018-08-27 18:39, Samuel Erdtman wrote:

+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 > 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

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Ludwig Seitz]

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




-Original Message-
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.

~snip~


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


[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?



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

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Samuel Erdtman]

+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  wrote:

>
>
> > -Original Message-
> > From: Ace  On Behalf Of Ludwig Seitz
> > Sent: Monday, August 27, 2018 12:52 AM
> > To: ace@ietf.org
> > Subject: [Ace] Parameter abbreviation number ranges for
> draft-ietf-ace-oauth-
> > authz
> >
> > 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
>
> [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.
> > 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
> >
> > ___
> > Ace mailing list
> > Ace@ietf.org
> > https://www.ietf.org/mailman/listinfo/ace
>
> ___
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Jim Schaad]

> -Original Message-
> From: Ace  On Behalf Of Ludwig Seitz
> Sent: Monday, August 27, 2018 12:52 AM
> To: ace@ietf.org
> Subject: [Ace] Parameter abbreviation number ranges for
draft-ietf-ace-oauth-
> authz
> 
> 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

[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.
> 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
> 
> ___
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Ludwig Seitz]

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

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace