> -----Original Message-----
> From: Ace <[email protected]> On Behalf Of Ludwig Seitz
> Sent: Monday, August 27, 2018 12:52 AM
> To: [email protected]
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
