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

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 12 November 2018 17:47 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8D0130DE2 for <ace@ietfa.amsl.com>; Mon, 12 Nov 2018 09:47:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqgn3DIZtnQC for <ace@ietfa.amsl.com>; Mon, 12 Nov 2018 09:47:32 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77695130DC6 for <ace@ietf.org>; Mon, 12 Nov 2018 09:47:32 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4FC542008C; Mon, 12 Nov 2018 12:47:26 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 3E63ACA1; Mon, 12 Nov 2018 12:47:30 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3C4409DB; Mon, 12 Nov 2018 12:47:30 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Ludwig Seitz <ludwig.seitz@ri.se>
cc: "ace\@ietf.org" <ace@ietf.org>
In-Reply-To: <39e815e5-e602-0253-d324-13fb48f92d3a@ri.se>
References: <39e815e5-e602-0253-d324-13fb48f92d3a@ri.se>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Mon, 12 Nov 2018 12:47:30 -0500
Message-ID: <16461.1542044850@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/5h4Hqt9H8nyZCJy7YiGi4AoWcn4>
Subject: Re: [Ace] Resume of discussion at IETF 103 meeting on draft-ietf-ace-oauth-authz
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Nov 2018 17:47:35 -0000

Ludwig Seitz <ludwig.seitz@ri.se>; 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  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [