Re: [OAUTH-WG] [DPoP] Order of validation for DPoP proofs and access tokens

Dmitry Telegin <dmitryt@backbase.com> Wed, 10 November 2021 19:09 UTC

Return-Path: <dmitryt@backbase.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 7C46C3A0F04 for <oauth@ietfa.amsl.com>; Wed, 10 Nov 2021 11:09:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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=backbase.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 eFHwTRp9q1gl for <oauth@ietfa.amsl.com>; Wed, 10 Nov 2021 11:08:58 -0800 (PST)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 BA02E3A0814 for <oauth@ietf.org>; Wed, 10 Nov 2021 11:08:57 -0800 (PST)
Received: by mail-lj1-x234.google.com with SMTP id 13so7199739ljj.11 for <oauth@ietf.org>; Wed, 10 Nov 2021 11:08:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=backbase.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lzy1lbQFonn73RjwbcfwW3C6RfE1sMgqUgVrkVrS3d0=; b=HL1wAAxPjTELqhIL5muHBmrXI/Wvf4QsSSjApuc3slMqOzNtHE2DTe21Hx5ll2V80W K5Gze3LTWOVe1NUl0tAq0mDu9pwXvyBEqqn+rZliAkJV9c3vIctbrPCgEfJI9R/B+Kp7 1CLaT0eZCMeiNi9Udt3eVdUc3XIRAF0Giue97q7AhHUH1jLrClUnV+DoB8tdryApZvWv lJdC+TRdH958WnbNBCswRBxPmtgZHB86C4HTFxQv4jX8v92VTgOxoFmy1DrTnCZAHwuU X5e0Qu64LtTsWnX+IQjBl9LZGG39YPgcphcrvXH93N4am+jITGNG4NK35CNYds23dDr5 HMLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lzy1lbQFonn73RjwbcfwW3C6RfE1sMgqUgVrkVrS3d0=; b=2ByamsY/NA+mv2flW4X2g8qrOf7Q0hLvnVZp0reu9dC+nEFS7xoXaV0mr3emsNU+9g DAtHPbkFoWZPYQS9648k5KKzfeU4Jv8WbKsNSZzRLVXZZrhJ6Zk7ICH2iKO5Tvum+gD8 oSSG2tuJLK9emGuRSF4bbTGvWrFJfnY5/5LizmPbVFQkPJlkGLcjvT/dBPlYS+FJXXm6 trQVixQMFsrWMV3sQbVKN2dTqnHROcn/k7fg8vDssDUpEqEfOcH4WGxoByuMfas8PWqQ YhIiGQnm8zkcq++zq1LQo8W/IrMTgpEHEzv91/TPf4qGrn+PeemS0s/7wXLPawGW8gIM /SOg==
X-Gm-Message-State: AOAM530skElBJtEdhdQ/GXKw5bMU8+hgmpsFCkm4QqpSHepTat/939Fd kxVgW8cUcr38QjPnL0qEdul32p7uuhmEADRxmd0PZDNXJOZBAfDHwB2w/Z/iL85b9lIBBoXYHM5 1UxdoRrlvrrflAiliKKGb
X-Google-Smtp-Source: ABdhPJxipNOEYXdAewVd8483OiSFZq++RjjI/LN9jUTkGX0DvRx/J00YP0e6Y2HxEJf3dv4wRNlwwcSSuG0IjclYKTM=
X-Received: by 2002:a05:651c:98c:: with SMTP id b12mr1226216ljq.481.1636571330980; Wed, 10 Nov 2021 11:08:50 -0800 (PST)
MIME-Version: 1.0
References: <CAOtx8Dnpunkn4Kz091cizK97zYvzqYdfekxW-cW-zj2s1U5r1A@mail.gmail.com> <CAOtx8DnQZE6B5o8Q1rxNFKzEPxd5fSaEhB-xHLBzLPrOcTmD0g@mail.gmail.com> <CA+k3eCT+fsFemHeMH69cDJ3oVMr1sDxtD=ADfnHeggY=dfHTgQ@mail.gmail.com> <47F47ACD-FA9E-4321-A380-D5A32143FC08@forgerock.com>
In-Reply-To: <47F47ACD-FA9E-4321-A380-D5A32143FC08@forgerock.com>
From: Dmitry Telegin <dmitryt@backbase.com>
Date: Wed, 10 Nov 2021 22:08:40 +0300
Message-ID: <CAOtx8DkC=b+gEGMH+eU6sqqUM+W0bJF=Sn_RZgDfR8F1fSAwiA@mail.gmail.com>
To: Neil Madden <neil.madden@forgerock.com>
Cc: Brian Campbell <bcampbell@pingidentity.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d5668705d073f410"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/SaKVXSPTA6Gi5FTWI0GmRY-bYd0>
Subject: Re: [OAUTH-WG] [DPoP] Order of validation for DPoP proofs and access tokens
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: Wed, 10 Nov 2021 19:09:04 -0000

Brian, Neil, thanks for the answers,

Now if we consider Token endpoint instead of UserInfo, in your opinion,
what should take priority in case both DPoP proof and provided credentials
are invalid? Should it be "invalid_grant" or "invalid_dpop_proof"?

The DPoP draft says:

To sender-constrain the access token, *after* checking the validity of the
> DPoP proof, the authorization server associates the issued access token
> with the public key from the DPoP proof
>

But it doesn't specify whether the credentials should be validated before
or after DPoP proof validation.

- Dmitry

On Wed, Oct 27, 2021 at 6:24 PM Neil Madden <neil.madden@forgerock.com>
wrote:

> I would express a mild preference for “invalid_token” taking priority in
> this case. It seems pointless for the client to generate a new DPoP proof
> (in response to invalid_dpop_proof) if they are then going to get an
> invalid_token on the next request anyway. If they get a new AT they will
> naturally generate a new proof too as the AT hash will no longer match.
>
> — Neil
>
> On 27 Oct 2021, at 16:20, Brian Campbell <
> bcampbell=40pingidentity.com@dmarc.ietf.org> wrote:
>
> It's really just an implementation choice, I think.
>
> On Wed, Oct 27, 2021 at 7:17 AM Dmitry Telegin <dmitryt=
> 40backbase.com@dmarc.ietf.org> wrote:
>
>> Any updates on this one? As of -04 we have a clear distinction between
>> "error=invalid_token" and "error=invalid_dpop_proof", so the question could
>> be reworded like this:
>> - if DPoP proof is used in combination with access token, and both are
>> invalid, which one of the "invalid_token" and "invalid_dpop_proof" should
>> be signaled?
>>
>> Regards,
>> Dmitry
>> Backbase
>>
>> On Fri, Jul 30, 2021 at 6:37 PM Dmitry Telegin <dmitryt@backbase.com>
>> wrote:
>>
>>> Hello,
>>>
>>> When DPoP proof is used in conjunction with a token (protected resource
>>> access; token refresh), what should be the order of validation of those?
>>> The draft doesn't mention this, and it's hard to deduce logically which
>>> should come first, since validation is mutual ("ath" DPoP claim vs.
>>> "cnf/jkt" token claim) and there is a sort of circular dependency. Are we
>>> going to address that in the spec, or intentionally leave as unspecified?
>>>
>>> Background: a developer asked me if it's guaranteed that the protected
>>> resource return a 401 in the case of invalid access token; currently, the
>>> answer seems to be "implementation specific".
>>>
>>> Regards,
>>> Dmitry
>>>
>>>
>>>
>>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>