IETF Logo Mail Archive

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

Neil Madden <neil.madden@forgerock.com> Sun, 07 June 2020 11:49 UTC

Return-Path: <neil.madden@forgerock.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 D8C393A00B0 for <oauth@ietfa.amsl.com>; Sun, 7 Jun 2020 04:49:35 -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, 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 (1024-bit key) header.d=forgerock.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 f0KIk4HKhOxk for <oauth@ietfa.amsl.com>; Sun, 7 Jun 2020 04:49:33 -0700 (PDT)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 EAC003A00AE for <oauth@ietf.org>; Sun, 7 Jun 2020 04:49:32 -0700 (PDT)
Received: by mail-wr1-x432.google.com with SMTP id x13so14413659wrv.4 for <oauth@ietf.org>; Sun, 07 Jun 2020 04:49:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=6sm6cGBp+E/9ECzP5fY8fe7I1lmL5KNgQFSeXl195yI=; b=jTpuqnJxdkUUOLC7D3Jbo/R4OTzvy9LomLOTty+2KBJIuQKdc4qMGTFlfuqTnx1XFZ mks34VQ9HsTsJW3RrmoXABBPRyG8/3buGDXk3j4uNf9TDxVtsOZG5dy4J4yc2ScvglQb YREGf8EMqwX3xOD6eXFISdhZrHhcXq4N0GXus=
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=6sm6cGBp+E/9ECzP5fY8fe7I1lmL5KNgQFSeXl195yI=; b=ekVzBv16v9wAYj2gIRNiOz1VxQWXeWQz4n8ZWU27aIl+K2fc4zX23+44UT9U6aefk2 WcRXOwiYIZLTvtGEx8UksK8VB2UuDZoOFvBPF9JuPju5XSXZFAxIpSPNmjy9umg1gpYo t4NOapHZ5Ar4jCPynJseQ38edZ8q+/BvNmT1MDlACwHPe8HIab0A+MNg6RiizKlaQZPJ CV60PGCFBvtG4mHhG3ZRndgB3knRxwxd/lNilDUSCp+/rTBzKXB+jRlH5VSmM93unID8 mOasnlNxgZ5x32D3pvsGx60v3h9HLjfJwVR6CJqQ+rHrD+5d/727/XPTVhY/KaCHpSWS GnPg==
X-Gm-Message-State: AOAM532uAQ/M6txijOwwDFFxQZ2ZCb/vm34a/98wKol+uf8Wp/fnuSYS BqTBlvptnFuPwWwh+oQqv2l33A==
X-Google-Smtp-Source: ABdhPJygK3d0KEZKbuR6KkH6R61DznHb7DxyoSjth6N1pEI0+W+vo+0DWq9C2ueEavZr1dZt4jH8gQ==
X-Received: by 2002:adf:f450:: with SMTP id f16mr18657711wrp.307.1591530571235; Sun, 07 Jun 2020 04:49:31 -0700 (PDT)
Received: from [10.0.0.3] (214.249.143.150.dyn.plus.net. [150.143.249.214]) by smtp.gmail.com with ESMTPSA id d191sm18771146wmd.44.2020.06.07.04.49.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jun 2020 04:49:30 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-4CE14C89-114C-4AF7-A471-FA31F1927791"
Content-Transfer-Encoding: 7bit
From: Neil Madden <neil.madden@forgerock.com>
Mime-Version: 1.0 (1.0)
Date: Sun, 07 Jun 2020 12:49:30 +0100
Message-Id: <09EC9AF5-C886-4852-9E05-9A8BEE1EE234@forgerock.com>
References: <BE34F5A7-7E00-48AC-8DAC-5F29235C3528@gmail.com>
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, oauth <oauth@ietf.org>
In-Reply-To: <BE34F5A7-7E00-48AC-8DAC-5F29235C3528@gmail.com>
To: Nov Matake <matake@gmail.com>
X-Mailer: iPhone Mail (17E262)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/GNFZNKPZQD2S40y9k3kFhzI8MyI>
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 11:49:36 -0000

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>のメール:
>> 
>> 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>:
>>>> 
>>> 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>のメール:
>>>> 
>>>> 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>:
>>>>>> 
>>>>> DPoP-bound refresh token seems feature duplication with dynamic client registration.
>>>>> 
>>>>>> 2020/06/07 7:57、Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org>のメール:
>>>>>> 
>>>>>>> 
>>>>>>> > 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

v2.23.0 | Report a Bug | By Email