Re: [Ace] WGLC for draft-ietf-ace-oauth-params

Ludwig Seitz <ludwig.seitz@ri.se> Tue, 23 October 2018 07:50 UTC

Return-Path: <ludwig.seitz@ri.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 121AB130EBC; Tue, 23 Oct 2018 00:50:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 ML7aYqEGxrn2; Tue, 23 Oct 2018 00:50:02 -0700 (PDT)
Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.33]) (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 8E4D5130DDB; Tue, 23 Oct 2018 00:50:01 -0700 (PDT)
Received: from 1gErRv-000jli-TH by out10d.electric.net with emc1-ok (Exim 4.90_1) (envelope-from <ludwig.seitz@ri.se>) id 1gErRv-000jml-V7; Tue, 23 Oct 2018 00:49:59 -0700
Received: by emcmailer; Tue, 23 Oct 2018 00:49:59 -0700
Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10d.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from <ludwig.seitz@ri.se>) id 1gErRv-000jli-TH; Tue, 23 Oct 2018 00:49:59 -0700
Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Tue, 23 Oct 2018 09:49:58 +0200
To: Jim Schaad <ietf@augustcellars.com>, ace@ietf.org, draft-ietf-ace-oauth-params@ietf.org
References: <065d01d45f4e$bc227690$346763b0$@augustcellars.com> <028f01d46a3a$c04bfd80$40e3f880$@augustcellars.com>
From: Ludwig Seitz <ludwig.seitz@ri.se>
Message-ID: <c1007eaa-e70f-ba58-ec92-eefdca650f8d@ri.se>
Date: Tue, 23 Oct 2018 09:49:58 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <028f01d46a3a$c04bfd80$40e3f880$@augustcellars.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.116.0.226]
X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162)
X-Outbound-IP: 194.218.146.197
X-Env-From: ludwig.seitz@ri.se
X-Proto: esmtps
X-Revdns:
X-HELO: sp-mail-2.sp.se
X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128
X-Authenticated_ID:
X-Virus-Status: Scanned by VirusSMART (c)
X-Virus-Status: Scanned by VirusSMART (s)
X-PolicySMART: 14510320
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/Sf-7EuXlME4ZUsY_L5EX04mVCRs>
Subject: Re: [Ace] WGLC for draft-ietf-ace-oauth-params
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: Tue, 23 Oct 2018 07:50:05 -0000

On 22/10/2018 21:09, Jim Schaad wrote:
> Here are my WGLC comments:
> 
> *  I am not sure that I understand what the protocol flow is when JAR is
> being used.  Is there a potential case where a JWT would be used as the
> structure of an OAuth response?  If so then is there a problem with defining
> cnf in section 4.1?

I wouldn't think so, all the other possible parameters in the 
introspection response are defined to be the claims of the token in RFC 
7662, cnf is a claim of the token, so I don't see why it shouldn't go 
unchanged into the introspection response.
> 
> * We need to have a OAuth CBOR integer mapping registry - the items in
> section 6 need to be registered into that registry.

That was an oversight. Issue created.

> 
> * Review - is the 'cnf' parameter in section 3.2 ok with the OAuth group or
> does it need to be renamed as well?
> 

I don't see how this could collide with another meaning. The AS is 
responding with the token and additional information about the token 
here. This parameter was called 'key' in 
draft-ietf-oauth-pop-key-distribution, which felt more phrone to 
misunderstandings to me ("what key?").


> * Check that cnf in 4.1 is going to be ok with
> draft-ietf-oauth-jwt-introspection-response
> 

If I understood it correctly draft only proposes to replace the whole 
introspection response with a JWT. I don't see why this shouldn't work 
with a CWT as well. No additional data but the JWT/CWT would be sent in 
the introspection response, so there should not be any issue with the 
cnf claim here.


-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51