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

[Samuel Erdtman <[e-mail]>]

+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 <[e-mail]> wrote:

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