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

Jim Schaad <ietf@augustcellars.com> Thu, 31 January 2019 16:44 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 1B35612426E; Thu, 31 Jan 2019 08:44:48 -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 TBjzs8cqguQx; Thu, 31 Jan 2019 08:44:45 -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 2FC4112426A; Thu, 31 Jan 2019 08:44:45 -0800 (PST)
Received: from Jude (67.208.104.26) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 31 Jan 2019 08:44:19 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'Ludwig Seitz' <ludwig.seitz@ri.se>, <draft-ietf-ace-oauth-authz@ietf.org>
CC: <ace@ietf.org>
References: <01e801d4b861$4d7d41e0$e877c5a0$@augustcellars.com> <76f048fa-fa03-4e5b-0b60-c5674a2ddad3@ri.se> <021c01d4b8c8$e5ee0ba0$b1ca22e0$@augustcellars.com> <c0163315-a62d-fe8a-be45-cabbaefc95f3@ri.se>
In-Reply-To: <c0163315-a62d-fe8a-be45-cabbaefc95f3@ri.se>
Date: Thu, 31 Jan 2019 08:44:16 -0800
Message-ID: <026b01d4b984$35f0c460$a1d24d20$@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: AQMO0G41vSMoQObT7FZTfu2Mz+Bo2AG5F3ZkAWTDHEsColIqPaMnZcbA
Content-Language: en-us
X-Originating-IP: [67.208.104.26]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/6Ov9mRZtdtdXHb_tlefytbWn-ho>
Subject: Re: [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: Thu, 31 Jan 2019 16:44:48 -0000


> -----Original Message-----
> From: Ludwig Seitz <ludwig.seitz@ri.se>
> Sent: Thursday, January 31, 2019 1:20 AM
> To: Jim Schaad <ietf@augustcellars.com>om>; draft-ietf-ace-oauth-
> authz@ietf.org
> Cc: ace@ietf.org
> Subject: Re: Shepard review for draft-ietf-ace-oauth-authz
> 
> On 30/01/2019 19:23, Jim Schaad wrote:
> >
> >
> >> -----Original Message----- From: Ludwig Seitz <ludwig.seitz@ri.se>
> >> Sent: Wednesday, January 30, 2019 12:38 AM To: Jim Schaad
> >> <ietf@augustcellars.com>om>; draft-ietf-ace-oauth- authz@ietf.org Cc:
> >> ace@ietf.org Subject: Re: Shepard review for
> >> draft-ietf-ace-oauth-authz
> >>
> >> Thank you Jim,
> >>
> >> I'll upload a new version as soon as we have resolved my questions
> >> below.
> >>
> >> /Ludwig
> >>
> >> On 30/01/2019 07:01, Jim Schaad wrote:
> >>> 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.
> >>
> >> That text just describes how it is in OAuth 2.0 (where refresh tokens
> >> are strings), since we didn't see the need to specify the use of
> >> refresh tokens in ACE, we didn't mention them further. If we had we
> >> would certainly have defined them to be binary.
> >
> > That would be fine, but you actually do define a CBOR mapping tag for
> > refresh tokens in the body of the text and define it as binary.
> >
> Right,
> (background: I did define a mapping for all OAuth parameters and re-
> mapped all that were Strings to binary. That does not necessarily mean the
> have a use case currently in ACE.)
> 
> in order to resolve this I will add a sentence in the description of the refresh
> token, saying that we define them to be binary here.
> 
> 
> >>> ****** IANA Section Issues
> >>>
> >>> 1.  None of the new registries appear to have any guidance for
> >>> the DEs to use when approving items.
> >>
> >> Is it acceptable to add a single guidance section for all of the
> >> new registries, or does it need to be separate for each of them?
> >
> > As long as the guidance is comment this is fine.  That is what I did
> > for all of the COSE registries
> >
> 
> I'll copy liberally from your example then (and a bit from the CWT RFC).
> Hope you don't mind.

I never really object to copying things that work.  Just think for a bit f anything is missing.  I will probably be doing some expanding of them in the move forward to Full Standard.

> 
> 
> >>>
> >>> 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.
> >>>
> >> Would "ACE Authorization Server Discovery Hints" be better?
> >
> > I thought about that, but it does not really cover the idea of having
> > the nonce value there or the possibility of later adding things like
> > - ok you should use this audience or this scope or some other similar
> > thing.
> >
> 
> I see. I'll use the somewhat clunky but descriptive "ACE Authorization
> Server Request Creation Hints".
> 
> I've also taken the liberty of adding audience (req_aud) and scope as
> optional parameters in the AS Request Creation Hints message, in order
> to justify its name.

I have always thought that those two items should be there anyway.  

Jim

> 
> 
> 
> While resolving issues from the DTLS profile the authors have noticed
> two elements that need to be added to the framework:
> 
> 1.) A definition of "Authorization Information"
> "The information an RS uses to determine wether a request is authorized,
> including the claims of applicable access tokens."
> 
> 2.) Adding the "kid" parameter to the AS Request Creation Hints, so that
> a client can request a token with the same pop key when it has an
> existing security association, but the token has expired.
> The procedure is currently defined in the DTLS profile, but it applies
> to any other profile as well and should therefore be in the framework.
> 
> 
> /Ludwig
> 
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51