[Ace] Shepard review for draft-ietf-ace-oauth-authz

Jim Schaad <ietf@augustcellars.com> Wed, 30 January 2019 06:02 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 351071311AB; Tue, 29 Jan 2019 22:02:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 a4IibjxEFCzg; Tue, 29 Jan 2019 22:01:59 -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 1D7AB1311AD; Tue, 29 Jan 2019 22:01:59 -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; Tue, 29 Jan 2019 22:01:53 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: <draft-ietf-ace-oauth-authz@ietf.org>
CC: <ace@ietf.org>
Date: Tue, 29 Jan 2019 22:01:52 -0800
Message-ID: <01e801d4b861$4d7d41e0$e877c5a0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdS4IFhTaN2qYeA7Q3O6kMo5VP3Q4A==
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/k3L5XTY4sXSaKh2ajxjeHYJg1M8>
Subject: [Ace] Shepard review for 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: Wed, 30 Jan 2019 06:02:01 -0000

1. Update the reference from RFC 5246 to RFC 8446 in all locations



Items that don't appear to be resolved:

* Section 3.1 - Refresh Token - I don't think that refresh tokens are going
to be strings because binary is more efficient.  
	 Unless you are going to say that this is not OAuth 2.0, then a
refresh token is still a text string.

*  I don't see any text that is addressing this.

> On 22/10/2018 21:09, Jim Schaad wrote:
> > * Section 5.8.2 - If the RS is going to do introspection, can it send
some
> > type of "Server Busy - try again in xxx" while it does the introspection
> > rather than just doing an ack of the request and possibly waiting a long
> > time?
> 
> This is probably transport protocol specific, and we were asked not to 
> link the framework to a specific protocol, thus I don't know if we can 
> provide guidance here.

I think it would be okay to say something like "some transport protocols
may provide a way to indicate that the server is busy and the client should
retry after an interval; this type of status update would be appropriate
while the server is waiting for an introspection response".  Which does
provide guidance, but in a non-normative fashion that does not require or
prohibit any given transport protocol.

*  I don't see anything that I think addresses this issue.  I would expect
it to be a security consideration

Comments on protection of CWT/Token:  I am wondering if there needs to be
any comments on how a CWT is going to be protected.  While it is ok to use
either a symmetric key or a direct key agreement operation for a single
recipient without forcing a signature operation to occur.  If the token is
going to be targeted a single audience hosted on multiple RSs then a
signature operation would be required for the purposes of authentication.  

****** IANA Section Issues

1.  None of the new registries appear to have any guidance for the DEs to
use when approving items.

2.  The title of the registry "ACE Authorization Server Information" is not
really descriptive of what is in the registry.   It makes sense in the text
but not as a stand along title.  Something along the lines of "ACE
Authorization Server Request Creation Hints" seems to be closer to a solid
identification.

3.  The mapping registries should use the OAuth registry name as a prefix.
Thus "OAuth Access Token Types" and "OAuth Access Token Type CBOR Mappings".

4.  What is the initial registrations that need to occur for the "ACE
Profile" registry.  If there are none then this needs to be stated.

5. For the CBOR Web Token Claims - how many of these should have the JWT
Claim name filled in?  It would seem that all of them should.  If not a
comment about this is needed.


Jim