Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

Nov Matake <matake@gmail.com> Sun, 07 June 2020 14:18 UTC

Return-Path: <matake@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9DB3A087F for <oauth@ietfa.amsl.com>; Sun, 7 Jun 2020 07:18:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 qbtwJKea5yqV for <oauth@ietfa.amsl.com>; Sun, 7 Jun 2020 07:18:37 -0700 (PDT)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9019E3A087C for <oauth@ietf.org>; Sun, 7 Jun 2020 07:18:37 -0700 (PDT)
Received: by mail-pl1-x62b.google.com with SMTP id d8so2438575plo.12 for <oauth@ietf.org>; Sun, 07 Jun 2020 07:18:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=p2WW3npujaUPXCEbQXCmiDaEk+GKeaqqC2rPvK08aaw=; b=YZLjT6wSYnauHJm0h7tAKeWdcBrRyCkB+XYCDEfbC1z/v8/qdnEcv4rQjJXHdgY2Dh g/Vq+yiDclyTgmeC82+D1Cy/EN8Z9EgywUK8YDV+/IHD9aPeaK3z/RnLl3/VDbjjZffi E/LkgSpDKhOAeM485May4Ssi2Xy6tW0CYoP0gLbkQWd/4HRPoE+n18tZbITBygrnb/xT 7h5nlVqCxx+2ObJRPbOlcFfwiKVox+VBc+8ityTaN0wsgcvNvO2xLB3GenrvZF2KLc0E phD0tueoWzC5yOgP/cL6uHuUqm01K85YAU9DwBNGVjrrQ7BPQKnvLZLk6HRGcM0/TblR dGtg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=p2WW3npujaUPXCEbQXCmiDaEk+GKeaqqC2rPvK08aaw=; b=jfJxoLBp94CMfVX6tONP+dfI5G4e391vpBTa+TDxswPvAGG16RRz4OvZCx9NBA/GLS 7KQqsCU1Nt/ZjCUWKH7Nm1wWxLVxIH/SA0TtPjLfSqVm9btiGo3blb3/XXOhjcipQVg6 MJRK0T1tSWxZJeWTs9zoXnBlQu0k1qFd4BUkY20P1242ej3RaQBrqpOS9UhxoyZIG5Uu 4M+vPrEmRXslLqz67AjXCN8zqJWNuGu9Rk++Sh3fWEjYcteYcIK6ZChyuirclsjqk+5V /50Ck5J0ux9bCdN666cZRoXJtJKEh8++DIyHDJZE6uNc0EEhNFHUbPWonBrPHCrW2e7B 2+Dw==
X-Gm-Message-State: AOAM530LF6fc8Kz0yH7okg01UdPtnoRaRbLKSkufU39cOCyiLuWkS0fZ O4EEmy5MNRJzU83TBv/hqks=
X-Google-Smtp-Source: ABdhPJx0YB/fwOsp0eejW0L+izR48JMgIVyz8tdAw14WLamyFbJsJ9Xv1TWvTzR2VahtYbQh2ibvpg==
X-Received: by 2002:a17:90a:cf17:: with SMTP id h23mr12877265pju.139.1591539516803; Sun, 07 Jun 2020 07:18:36 -0700 (PDT)
Received: from [172.16.80.79] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id a14sm4444151pfc.133.2020.06.07.07.18.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Jun 2020 07:18:36 -0700 (PDT)
From: Nov Matake <matake@gmail.com>
Message-Id: <AE81333F-F19B-4C00-AF21-64310BF56704@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9CEA000A-3B2E-4CC4-9828-3D019FC64F5C"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Sun, 7 Jun 2020 23:18:33 +0900
In-Reply-To: <CAOW4vyOL0ZTZKpMghVLEmFmaaBq+nZCZ1b8KPZKetsa9c=fPnw@mail.gmail.com>
Cc: Neil Madden <neil.madden@forgerock.com>, oauth <oauth@ietf.org>
To: Francis Pouatcha <fpo@adorsys.de>
References: <375FA230-5700-42A5-B933-2A37D296BCDF@forgerock.com> <AC87697A-07BC-43E6-82C3-73892A7C505D@gmail.com> <BB604649-B01B-460B-B312-126600CD69DE@gmail.com> <CAOW4vyOL0ZTZKpMghVLEmFmaaBq+nZCZ1b8KPZKetsa9c=fPnw@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/8rY_guElyyNKxKuhtrEa-Lk708s>
Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Jun 2020 14:18:40 -0000

private_key_jwt and mTLS can be sender PoP method for code too.

> 2020/06/07 23:00、Francis Pouatcha <fpo@adorsys.de>のメールt;のメール:
> 
> I am a little bit confused. Let me  break it down:
> 
> code :
>   -> sender : Client
>   -> consumer : AS
>   -> sender PoP : 
>        --> confidential client: code_verifier (PKCE)
>        --> public client:  code_verifier (PKCE)?
> 
> refresh_token :
>   -> sender : Client
>   -> consumer : AS
>   -> sender PoP : 
>        --> confidential client: private_key_jwt, mTLS
>        --> public client:  DPoP?
> 
> access_token :
>   -> presenter : Client
>   -> consumer : RS
>   -> sender PoP : 
>        --> confidential client: private_key_jwt, mTLS
>        --> public client:  DPoP?
>   
> Is this correct?
> 
> On Sun, Jun 7, 2020 at 8:42 AM Nov Matake <matake@gmail.com <mailto:matake@gmail.com>> wrote:
> * sender-constrained code, bearer access token and sender-constrained refresh token, use DynReg or "PKCE + DPoP allowing access token remaining bearer".
> * sender-constrained code, sender-constrained access token and sender-constrained refresh token, use "DynReg + DPoP" or "PKCE + DPoP".
> * bearer code, sender-constrained access token and sender-constrained refresh token, use DPoP only.
> * sender-constrained code, bearer access token and bearer refresh token, use PKCE only.
> * bearer code, bearer access token and bearer refresh token, use none of them.
> 
>> 2020/06/07 21:36、Nov Matake <matake@gmail.com <mailto:matake@gmail.com>>のメール:
>> 
>> Yeah, both PKCE and Client Credential provide sender-constrained code...
>> lots of choices
>> 
>> Sent from my iPhone
>> 
>>> On Jun 7, 2020, at 21:26, Neil Madden <neil.madden@forgerock.com <mailto:neil.madden@forgerock.com>> wrote:
>>> 
>>> 
>>> Answers inline: 
>>> 
>>>> On 7 Jun 2020, at 13:07, Nov Matake <matake@gmail.com <mailto:matake@gmail.com>> wrote:
>>>> 
>>>> So, you mean…
>>>> 
>>>> If a frontend client want to use
>>>> * sender-constrained code, bearer access token and sender-constrained refresh token, use DynReg.
>>> 
>>> I’m not really sure what a sender-constrained code would be, but I suspect the right answer here is PKCE + DPoP. PKCE basically is PoP for auth codes. 
>>> 
>>>> * sender-constrained code, sender-constrained access token and sender-constrained refresh token, use DynReg + DPoP.
>>> 
>>> PKCE + DPoP
>>> 
>>>> * bearer code, sender-constrained access token and sender-constrained refresh token, use DPoP only.
>>> 
>>> Sure, but you should always use PKCE, so PKCE + DPoP. 
>>> 
>>>> * bearer code, bearer access token and bearer refresh token, use neither.
>>>> 
>>>> is my understanding correct??
>>> 
>>> Just use PKCE + DPoP. (Or a different PoP mechanism, eg mTLS cert-bound tokens, or etc). 
>>> 
>>>> 
>>>>> 2020/06/07 20:49、Neil Madden <neil.madden@forgerock.com <mailto:neil.madden@forgerock.com>>のメール:
>>>>> 
>>>>> There are multiple issues with using dynamic client registration for this. If a user uninstalls and later reinstalls an app then they can end up with multiple registrations for the same client, which makes it harder for them to manage access. Additionally, client registrations typically don’t expire so the AS doesn’t know when it can remove unused clients.
>>>>> 
>>>>> Besides, this ship already sailed with mTLS cert-bound refresh tokens. 
>>>>> 
>>>>> Neil
>>>>> 
> 
> 
> -- 
> Francis Pouatcha
> Co-Founder and Technical Lead at adorys
> https://adorsys-platform.de/solutions/ <https://adorsys-platform.de/solutions/>