+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 protected]> wrote:
> > > > -----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 >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
