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

Nov Matake <matake@gmail.com> Sun, 07 June 2020 12:36 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 3401C3A07A6 for <oauth@ietfa.amsl.com>; Sun, 7 Jun 2020 05:36:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, MIME_QP_LONG_LINE=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 wQpnU45OWHbr for <oauth@ietfa.amsl.com>; Sun, 7 Jun 2020 05:36:46 -0700 (PDT)
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 3A8FD3A07A0 for <oauth@ietf.org>; Sun, 7 Jun 2020 05:36:46 -0700 (PDT)
Received: by mail-pl1-x62f.google.com with SMTP id q16so5567504plr.2 for <oauth@ietf.org>; Sun, 07 Jun 2020 05:36:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=WA2Du4DAP1Zrz2VBaFhyE4kwaSKPDswBebXwgYVJoSs=; b=X/uZDbRT/d/fktWaMkuzm4075J+pvOqrB5FTrYZ4go+1LtaoDRry2YlYnxxt5dV3AH y/ABqnkEMGIeuJK12slL/D5qm/BaNc5lJrC1m9A1n0i8RUjBrchiB1Z+qVz/q9suYwtN EFd7RlLsg0rIu8AwpjXw6QwIfkvCnAJ9mr0zwLN6P6iCpNoLMtBp6X6q6VoJdSI/Fver RWfHNwlIlCO6/VRo9tUkE+hfzV88+mD7381Ri8wI2U0huSXU2hGHBBdrgAnkPx5QQ9WC T99sgX3EHKa3kCpjWRkfuLAjCDJYfQNFh9npEVJ01SjxFPgRq+SrCts1KopvkXfv788K birg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=WA2Du4DAP1Zrz2VBaFhyE4kwaSKPDswBebXwgYVJoSs=; b=siaCEzpU57MMVr1QUMUvn7t7GumuYR/Z6OYyJTyFsAzOmz5imUIC0k1OQRyWbsvB/5 gXkV8GPgULRgVYLrM3n5ROPknpfxnFBCPVkyLoAwHKWQWe7bON19YnbKpY0cxi80qlUO DujzZdHanCtR6yiHDAo+3lJVQnSgG5q2XvvNkIF9GtbNsuI/GtEBsMw4bVUBmSytSUkH eyudaR4WmE7bdxrTXJ1m/rRO+X7swrixrGoHSiwHH1w3PXOL++V0P/V4YpYRWEPCE3/8 LKm9dc+B6/91QFXA1VTQj2MbSjtyHXOTaRMUob5jkBPrFnX68LuHDUSAvBYr4EHHA48N vU4g==
X-Gm-Message-State: AOAM530mAjZp7gZP1ZM0l577eCAVCSER6n7VTmAsInJ7/m2ZdyDXxsel 1muInW3zYqa9XwMVQT7A5Qk=
X-Google-Smtp-Source: ABdhPJzu3B6nKkT0xZxvUndBto3BKvCLh2tBqr02GmlE3FFjKigzziVrZNJTJ7fd7KjMxqz5MOIfSg==
X-Received: by 2002:a17:902:a588:: with SMTP id az8mr16054786plb.318.1591533404156; Sun, 07 Jun 2020 05:36:44 -0700 (PDT)
Received: from [172.16.80.125] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id 71sm4460884pfb.20.2020.06.07.05.36.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jun 2020 05:36:43 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-9A0B9C10-8229-4C32-9362-BF72B51C0220
Content-Transfer-Encoding: 7bit
From: Nov Matake <matake@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Sun, 7 Jun 2020 21:36:41 +0900
Message-Id: <AC87697A-07BC-43E6-82C3-73892A7C505D@gmail.com>
References: <375FA230-5700-42A5-B933-2A37D296BCDF@forgerock.com>
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, oauth <oauth@ietf.org>
In-Reply-To: <375FA230-5700-42A5-B933-2A37D296BCDF@forgerock.com>
To: Neil Madden <neil.madden@forgerock.com>
X-Mailer: iPhone Mail (17F75)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/5C1UZdXGwurhpdXxAdteHJOsJB4>
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 12:36:48 -0000

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> wrote:
> 
> 
> Answers inline: 
> 
>>> On 7 Jun 2020, at 13:07, Nov Matake <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>のメールt;のメール:
>>> 
>>> 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
>>> 
>>>>> On 7 Jun 2020, at 12:34, Nov Matake <matake@gmail.com> wrote:
>>>>> 
>>>> Confidential clients can also use DPoP.
>>>> 
>>>>> 2020/06/07 20:25、Torsten Lodderstedt <torsten@lodderstedt.net>のメールt;のメール:
>>>>> 
>>>>> If the client would register for every transaction.
>>>>> 
>>>>> And don’t forget, DPoP also supports sender constrained access to resource servers, which dyn registration does not.
>>>>> 
>>>>>>> Am 07.06.2020 um 13:04 schrieb Nov Matake <matake@gmail.com>om>:
>>>>>>> 
>>>>>> Since each client instance has at least one key, those are same level of state management.
>>>>>> 
>>>>>>> 2020/06/07 16:24、Torsten Lodderstedt <torsten@lodderstedt.net>のメールt;のメール:
>>>>>>> 
>>>>>>> There are similarities in this particular use case but I would argue DPoP is more light weight than dynamic client registration, less state management in particular.
>>>>>>> 
>>>>>>>>> Am 07.06.2020 um 05:41 schrieb Nov Matake <matake@gmail.com>om>:
>>>>>>>>> 
>>>>>>>> DPoP-bound refresh token seems feature duplication with dynamic client registration.
>>>>>>>> 
>>>>>>>>> 2020/06/07 7:57、Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org>のメールt;のメール:
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> > Am 05.06.2020 um 22:17 schrieb George Fletcher <gffletch=40aol.com@dmarc..ietf.org>:
>>>>>>>>>> > 
>>>>>>>>>> > Secondly, I do think we need a way to allow for the refresh_token to be bound while leaving the access_tokens as bearer tokens. This adds useful security without impacting existing RS deployments.
>>>>>>>>>> 
>>>>>>>>>> +1 that’s a very useful feature_______________________________________________
>>>>>>>>> AFAIK a refresh_token is always bound. What am I missing here?
>>>>>>>>> -- 
>>>>>>>>> Francis Pouatcha
>>>>>>>>> Co-Founder and Technical Lead at adorys
>>>>>>>>> https://adorsys-platform.de/solutions/
>>>>>>>>> _______________________________________________
>>>>>>>>> OAuth mailing list
>>>>>>>>> OAuth@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>> 
>>>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>