Re: [Ace] Resume of discussion at IETF 103 meeting on draft-ietf-ace-oauth-authz

[Michael Richardson <[e-mail]>]

Ludwig Seitz <[e-mail]> wrote:
    > I wanted to post a resume of the in room discussions from the IETF 103
    > meeting, related to draft-ietf-ace-oauth-authz, for those who missed
    > them and those who want to further comment (sorry for the verbose
    > summary below):

    > During my presentation I put up a 7 issues for discussion as follows:


    > 1. Use of one-byte CBOR abbreviations for parameters and CWT claims.

    > So far there is a consensus between me and Mike Jones on what we think
    > is reasonable.

    > This would be summarized here:
    > https://www.ietf.org/mail-archive/web/ace/current/msg03053.html

This message seems to be about which ones get abbreviated.

I was thinking more that we need to have some process by which new
claim parameters get introduced, and how we observe they become popular, and
then then give them an abbreviation.

Unless I'm mistaken, a three character claim ("iss", "sub", etc.) will take
four bytes to encode.   That's not that expensive, but there are naturally a
limited number of interesting three letter codes.

Since we verify the signature and then interpret, (rather than interpret, try
to put it back into canonical order and verify), it seems that we can easily
replace longer codes with shorter ones as long as we can be sure our audience
knows the new shorter codes.

This last part seems the hardest part.

    > There were arguments for splitting this up so that we can re-use the
    > same compact one-byte abbreviations in those different "namespaces"
    > i.e. there would be a number range just for CWT claims, and a separate
    > one for introspection and token endpoint parameters.

    > Even here I'm interested in additional input.

I see both points of view, and I just don't know.
Clearly we need to decide *NOW* if want them to be seperate namespaces so
that programs build different tables.  If we later merge them, then that's
an easy transition.
Do they already have different IANA registries?  (I should know, but I don't)

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [