IETF Logo Mail Archive

Re: [Ace] OSCORE Profile IANA questions

Seitz Ludwig <ludwig.seitz@combitech.se> Wed, 02 September 2020 06:56 UTC

Return-Path: <ludwig.seitz@combitech.se>
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 90AA93A079F for <ace@ietfa.amsl.com>; Tue, 1 Sep 2020 23:56:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 R70EtnlYDiJ0 for <ace@ietfa.amsl.com>; Tue, 1 Sep 2020 23:56:18 -0700 (PDT)
Received: from weald.air.saab.se (weald.air.saab.se [136.163.212.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0EF3A078C for <ace@ietf.org>; Tue, 1 Sep 2020 23:56:16 -0700 (PDT)
Received: from mailhub2.air.saab.se ([136.163.213.5]) by weald.air.saab.se (8.14.4/8.14.4) with ESMTP id 0826u7tv031960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Sep 2020 08:56:07 +0200
DKIM-Filter: OpenDKIM Filter v2.11.0 weald.air.saab.se 0826u7tv031960
Received: from corpappl16595.corp.saab.se (corpappl16595.corp.saab.se [10.12.12.127]) by mailhub2.air.saab.se (8.13.8/8.13.8) with ESMTP id 0826tmAE013657 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Sep 2020 08:55:48 +0200
Received: from corpappl16595.corp.saab.se (10.12.12.127) by corpappl16595.corp.saab.se (10.12.12.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Wed, 2 Sep 2020 08:55:48 +0200
Received: from corpappl16595.corp.saab.se ([fe80::3c3e:6470:4c56:a86f]) by corpappl16595.corp.saab.se ([fe80::3c3e:6470:4c56:a86f%4]) with mapi id 15.01.1979.003; Wed, 2 Sep 2020 08:55:48 +0200
From: Seitz Ludwig <ludwig.seitz@combitech.se>
To: Francesca Palombini <francesca.palombini@ericsson.com>, Jim Schaad <ietf@augustcellars.com>, Ace Wg <ace@ietf.org>
Thread-Topic: OSCORE Profile IANA questions
Thread-Index: AQHWf5W01luwmoZHhU++qk7AvzRo4alSOI+ggAFfJoCAAVOIIA==
Date: Wed, 02 Sep 2020 06:55:48 +0000
Message-ID: <59a70cbc79d44723a7e08ba21cf9f453@combitech.se>
References: <40F43BA8-1127-4066-8A5E-6929F962B052@ericsson.com> <3547a70f710c48c1b84cd70b70e0e873@combitech.se> <C3DA541F-1AA4-4AA3-B000-06A1384A24F0@ericsson.com>
In-Reply-To: <C3DA541F-1AA4-4AA3-B000-06A1384A24F0@ericsson.com>
Accept-Language: en-SE, sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.12.13.199]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Saab-MailScanner-Information: Please contact the ISP for more information
X-Saab-MailScanner-ID: 0826tmAE013657
X-Saab-MailScanner: Found to be clean
X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.999, required 5, autolearn=not spam, ALL_TRUSTED -1.00, URIBL_BLOCKED 0.00)
X-Saab-MailScanner-From: ludwig.seitz@combitech.se
X-Saab-MailScanner-Watermark: 1599634554.00072@e3nqEt37aM8iG6FP5atISQ
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald.air.saab.se [136.163.212.3]); Wed, 02 Sep 2020 08:56:07 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/xdyxBFQjpkZ6iDqSLM_79aP9M30>
Subject: Re: [Ace] OSCORE Profile IANA questions
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: Wed, 02 Sep 2020 06:56:21 -0000

+1

(and I'd suggest names that make both "from" and "to" clear, e.g. "client-rs-request" or something like that)

 /Ludwig

-----Original Message-----
From: Francesca Palombini <francesca.palombini@ericsson.com> 
Sent: den 1 september 2020 10:34
To: Seitz Ludwig <ludwig.seitz@combitech.se>; Jim Schaad <ietf@augustcellars.com>; Ace Wg <ace@ietf.org>
Subject: Re: OSCORE Profile IANA questions

Hi Ludwig, Jim,

Thanks for your input.

Ludwig: I agree with you, they do not belong in the token request. I would be fine with not registering them as OAuth parameters and only register them as Ace parameters, but if I understand correctly the only way to register Ace parameters right now is:
1. register them in the OAuth Parameter Registry 2. register the CBOR mapping in the OAuth Parameters CBOR Mappings Registry.
Did I miss something? Is there a better registry where to put these? Otherwise I am ok with defining a new category, more on that below.

> [JLS] Look at the OAuth registries - they have some "standardized" names for these interactions as well as the RS-AS pair.

Jim: yes, they have standardized names, but as far as I can see only those 4 (token request/response, authorization request/response) are allowed in this registry (see https://tools.ietf.org/html/rfc6749#section-11.2.1 ), and they seem to indicate C-resource owner and C-AS messages.
I went and checked the registry [*], and there is actually one exception from Kantara UMA, they registered some parameters with the following locations: "client request", "token endpoint", " authorization server response". So now I am wondering what these locations mean, and how come they have managed to register parameters with locations outside of the template. I am fine with using "client request" and "resource server response" but these are not standardized names in OAuth.
I think the best way forward is: agree within the working group on some names (such as those above, or better ones if you have proposals), then request the OAuth Parameters Registry expert review, which is necessary for IANA ok.

~snip~

v2.23.0 | Report a Bug | By Email