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

Nov Matake <matake@gmail.com> Sun, 07 June 2020 12:07 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 8D3323A0602 for <oauth@ietfa.amsl.com>; Sun, 7 Jun 2020 05:07:50 -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 3nys2v1g9HZ9 for <oauth@ietfa.amsl.com>; Sun, 7 Jun 2020 05:07:48 -0700 (PDT)
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 366D23A060D for <oauth@ietf.org>; Sun, 7 Jun 2020 05:07:48 -0700 (PDT)
Received: by mail-pj1-x102d.google.com with SMTP id s88so4809463pjb.5 for <oauth@ietf.org>; Sun, 07 Jun 2020 05:07:48 -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=q1rn9lsxTBjQfwd69BtUrezAd7VRfEQkOkDJqRv5m54=; b=f5aFAonq21vuu6YV/MRsp4T1Ie4pqNz98UHOWGrNrGjQHjaCkM2L5TBT6xJZ2zLYVy d4a7nKGX+0c8Dbcxk5X+MHutmb8PW03XMgYowvFiv4SZQoRus3fQYUiTgiJrsNG/n72V Ttubb5I5PehbDNTU4gW1NH7rrENLweTTF3hwWmQyIzCzTVLAhrNMKKLfMyzbpslNIL7i wVH+CKfG6xuqXGDkJIiXCK0WBDKyK33d0d//xJM6GBvfOdagjOKptd+VXHiJZEiWCT/9 IMfbQVGqqZPLvSmNlfN+u2cPcEmUdaUwx35bHc1aPCImz+uGvdD+zT7bnLl1NCg1H95s lUpw==
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=q1rn9lsxTBjQfwd69BtUrezAd7VRfEQkOkDJqRv5m54=; b=kFrcRvOeyzIWeLQsMHm4Ca9iVR4fAd5Ck0tcPj0X3oeOE+vuC1nknLjFcC035ZJXQJ NjOVX8s9dXfIBCspCr1kR1YMm5kN7If662DmYaw0G/N8jP65Hjk7VtlgPzLOY89zcIoa yrHMqjjdOfSkIjQEOh7JQBefMSxPrtUXVCSMYJTcwX0+2SZekF8Wau7w6/wIFDXmRTEd DbMMBKd9fK1CZWjl6pIfyJmjqCDGr5T/KbIY1Jc5t08p8s1mCEdbV6I91ovuJJkOT3ID cFQ9IZ9U4tgddVBXbyFpfy96iffAELeIzYMAcvkQQ4QHvkhmGWSGj3l9BhoZ2VeDJjCo oC5A==
X-Gm-Message-State: AOAM5306cRWlA48jBht+QPLSjp+YsYWmjx2pnghwCadCtMnDHyDu7MFw 0W6V1C1GHXbnwZsRmuEC5Xc=
X-Google-Smtp-Source: ABdhPJwSqFsTXbA3ZDY08n5imhNyCa0GXmxh0x47JEQDCeZ/Mj2PQLGQX+1wKeYgatI5sXFlO6i54w==
X-Received: by 2002:a17:90a:e2c4:: with SMTP id fr4mr12280634pjb.32.1591531667515; Sun, 07 Jun 2020 05:07:47 -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 v3sm12588200pja.8.2020.06.07.05.07.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Jun 2020 05:07:46 -0700 (PDT)
From: Nov Matake <matake@gmail.com>
Message-Id: <4CAC2CCD-E776-455D-914C-7BBBA1912B32@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9ACE2C3D-2286-4991-81FF-B635432EA6DD"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Sun, 7 Jun 2020 21:07:44 +0900
In-Reply-To: <09EC9AF5-C886-4852-9E05-9A8BEE1EE234@forgerock.com>
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, oauth <oauth@ietf.org>
To: Neil Madden <neil.madden@forgerock.com>
References: <BE34F5A7-7E00-48AC-8DAC-5F29235C3528@gmail.com> <09EC9AF5-C886-4852-9E05-9A8BEE1EE234@forgerock.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/lpRQjn11AYWxQ6BJ6_SKffA8DL8>
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:07:51 -0000

So, you mean…

If a frontend client want to use
* sender-constrained code, bearer access token and sender-constrained refresh token, use DynReg.
* sender-constrained code, sender-constrained access token and sender-constrained refresh token, use DynReg + DPoP.
* bearer code, sender-constrained access token and sender-constrained refresh token, use DPoP only.
* bearer code, bearer access token and bearer refresh token, use neither.

is my understanding correct??

> 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 <mailto:torsten@lodderstedt.net>>のメール:
>>> 
>>> 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 <mailto:matake@gmail.com>>:
>>>> 
>>>> 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 <mailto:torsten@lodderstedt.net>>のメール:
>>>>> 
>>>>> 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 <mailto:matake@gmail.com>>:
>>>>>> 
>>>>>> DPoP-bound refresh token seems feature duplication with dynamic client registration.
>>>>>> 
>>>>>>> 2020/06/07 7:57、Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org <mailto:fpo=40adorsys.de@dmarc.ietf.org>>のメール:
>>>>>>> 
>>>>>>> 
>>>>>>> > Am 05.06.2020 um 22:17 schrieb George Fletcher <gffletch=40aol.com <http://40aol.com/>@dmarc..ietf.org <http://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/ <https://adorsys-platform.de/solutions/>_______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>>>> 
>>>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth