Re: [Ace] draft-ietf-ace-oauth-authz

Jim Schaad <ietf@augustcellars.com> Mon, 25 February 2019 17:08 UTC

Return-Path: <ietf@augustcellars.com>
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 917F4130F00; Mon, 25 Feb 2019 09:08:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Pe1lq3_MMFc5; Mon, 25 Feb 2019 09:08:51 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18576130F13; Mon, 25 Feb 2019 09:08:51 -0800 (PST)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 25 Feb 2019 09:08:44 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'Ludwig Seitz' <ludwig.seitz@ri.se>, <draft-ietf-ace-oauth-authz@ietf.org>
CC: 'ace' <ace@ietf.org>
References: <000201d4cbd5$d6837900$838a6b00$@augustcellars.com> <a4e42204-df48-f550-7e98-095bdbdd9ff3@ri.se>
In-Reply-To: <a4e42204-df48-f550-7e98-095bdbdd9ff3@ri.se>
Date: Mon, 25 Feb 2019 09:08:40 -0800
Message-ID: <00b001d4cd2c$c361f920$4a25eb60$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHtvGpMaQ5ktN+nGoFqPem4h+hCsQLbA0eppagHrVA=
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/ADMvZVoo2ITmaFVyI7lwF1rDKpk>
Subject: Re: [Ace] 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, 25 Feb 2019 17:08:55 -0000


> -----Original Message-----
> From: Ludwig Seitz <ludwig.seitz@ri.se>
> Sent: Monday, February 25, 2019 6:21 AM
> To: Jim Schaad <ietf@augustcellars.com>om>; draft-ietf-ace-oauth-
> authz@ietf.org
> Cc: 'ace' <ace@ietf.org>
> Subject: Re: draft-ietf-ace-oauth-authz
> 
> On 24/02/2019 01:13, Jim Schaad wrote:


> > 3. In section 8.3 - Is/Should there be a requirement that the error also be
> > registered in an OAuth registry?  If so then this needs to be part of the
> > expert reviewer instructions on this registry.
> 
> The expert reviewer instructions already state this:
> 
> "Since a high degree of overlap is expected between these registries
>   and the contents of the OAuth parameters registries, experts should
> require new registrations to maintain a reasonable level of alignment
> with parameters from OAuth that have comparable functionality."
> 
> This includes the error registry, do you think this is sufficiently
> clear or should I elaborate?

The question I had was the difference between SHOULD and MUST be registered.  The text there says - try and keep them in sync, but if they are not it is not a problem.   If that is what you want then this is not a problem, I was just validating this.

> 
> >
> > 4. In section 8.4 - Is there a reason to require a specification for this
> > registry?  Should it be sufficient to have somebody request that a mapping
> > be registered and the DE approves it?  The previous comment would apply
> to
> > all of the mapping registries that are just mappings.
> >
> The idea is to prevent the squatting of low byte count abbreviations by
> parameters that are not frequently used, thus there is a range of
> different policies for different integer abbreviation number ranges.
> (note: I'm following the example of the CWT specification here)

Not requiring a document to exists could still allow this.  IANA would still have the DE approve the assignment.

> >
> > 6. In section 8.9 - see comments of section 8.3 and 8.4
> >
> > 7.  In section 8.11 - see comments of section 8.3 and 8.4
> >
> See above
> 
> 
> > 8.  This document has an IPR disclosure on it.   If anybody has any problems
> > with the current disclosure then they need to speak up now.
> 
> Processing ...
> 
> The changes are currently only in the github version, I will upload a
> new version of the draft soon.
> 
> /Ludwig
> 
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51