Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

Brian Campbell <> Tue, 14 April 2020 21:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60F8F3A1078 for <>; Tue, 14 Apr 2020 14:39:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G1DofTp6A9Sn for <>; Tue, 14 Apr 2020 14:39:07 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 434913A107F for <>; Tue, 14 Apr 2020 14:39:06 -0700 (PDT)
Received: by with SMTP id j14so964982lfg.9 for <>; Tue, 14 Apr 2020 14:39:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vV/9B3xropFYwpZuzBwp8Owro/qkwgbT//Gc8RMqPBU=; b=BP/IEbb2m2jb3FIyepGTtQxpWGTFHuP0zR86SF0YKfcwo5PyXKVBaNJOqaAScgRfps tnBiwZeHLl9akswElZgf6NZJ7nXTogHvRVRqz1+9RVOE6JVSJCSawYMnfzHqTJdZf/0/ MOYWDiVkz9O2UjkVuHwgN0XzSc8gQSI8yC+mmcgcu9Q6rsYQUFLa71HNNUF0Poov8yYZ hs0JQurOHT9CxJJzKw4I2xZxIRJF/hN6hJB/3AEgLyDjZucbYQJ9J39Wl/kB9y4qmpcA mEOTwlQoMfKGjZPYGSv44OesYUuLCtY7XoZkxH3hKqTpQhb2fRDtY+f5XE3vMyXzBpRB KW5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vV/9B3xropFYwpZuzBwp8Owro/qkwgbT//Gc8RMqPBU=; b=oHJZ612+ZloJ3xkqtrR8FWFlDrC6qY72H3pHe53qDjxwyH2sL9H2KR+0wS/9HD5fKS itphJDRygO/HJDN7MiGAve9fGIkln+eZuJrRXQx/LWh0Exax3fItv1PGgKaVM8grfMHe Fq+vY9Ga433+hwLBnIrA+JIWWodj2b3Fk9ExZJeijMABKPKvBugSb/q1jd9G6EEwL3Gb n8ignLtt8RWyZxGs2uvyL/g3h3I+W5LFXXPap3n4npNDICeM46OPeJTxGdHtDsIOynOa xlSiw2b4Xp2z+SiQWnj/jWBhHNd57sy+K6FlrY0dW396aEJXIo8Zh0fpU8F4b25uhtYp GxAw==
X-Gm-Message-State: AGi0PuayOAKAcOichRTTR8OfNtxojKP55yT9zDuhLSbMduKGUeBUwx0X JGf0Afubq61foFKs6Qjd3W7OhgJ6p2hMADl/uFz34gR8rmGvhZSUrshL8V/lzLYBNoNhBAa6fL7 W5+tdpZiH1j5VoA==
X-Google-Smtp-Source: APiQypJAwX2N+tjDTLIcbfNxSc7GTPzTehsye81tS3Vdej06V+NRfCbwde9EbqIv0IgAIIj77dqisPwDYwFzoGKCC/k=
X-Received: by 2002:a05:6512:308c:: with SMTP id z12mr1031509lfd.195.1586900345049; Tue, 14 Apr 2020 14:39:05 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Brian Campbell <>
Date: Tue, 14 Apr 2020 15:38:38 -0600
Message-ID: <>
To: Filip Skokan <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="0000000000005c6a3605a347076d"
Archived-At: <>
Subject: Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Apr 2020 21:39:09 -0000

Hi Filip,

My attempts at responses to your questions/comments are inline:

On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan <> wrote:

> I've wondered about the decision to use a new scheme before
> <> but
> this time i'd like to challenge the immediate usability of the future spec
> for one specific case - sender constraining public client Refresh Tokens.

I'm still somewhat on the fence as to the pros and cons of using a new
token type and authorization scheme. But the draft has gone with a new one.
Would it have really helped this situation, if it'd stuck with "bearer"? Or
would it just be less obvious?

> If at all, it is going to take time for RS implementations to recognize
> the new `DPoP` authorization scheme, let alone process it properly. In the
> meantime, i'd still like to have the option to bind issued public client
> refresh tokens using DPoP without affecting the access tokens. In doing so
> i get an immediate win in sender constraining the refresh tokens but not
> introducing a breaking change for the RS.
>    - Do you see this as something an AS implementation is just free to do
>    since it's both the issuer and recipient of a refresh token?
> That's my first thought, yes.

>    - Should this be somehow baked in the draft?
> I'm not sure. Do you think it needs to be? I'm not sure what it would say

In such a case the AS could bind the RT to the given dpop proof and either
not bind the AT while returning token_type=Bearer or bind the AT while
returning token_type value DPoP. In the latter case the AT would almost
certainly still work as a bearer token at the RS and the client that knew
the RS's needs could send it as such with an `Authorization: Bearer <at>`.
Or if it didn't know the RS's needs, it could start with `Authorization:
DPoP <at>` which would get a 401 with `WWW-Authenticate: Bearer` at which
point it could send `Authorization: Bearer <at>`.

As I wrote the preceding rambling paragraph I am starting to think that
more should be said in the draft about working with RSs that don't support
DPoP. Which isn't really what you were asking about. But maybe would cover
some of the same ground.

>    - Do you think client registration metadata could be used to signal
>    such intent?
> I think it certainly could. But it seems maybe too specific to warrant

>    - Do you think the protocol should have signals in the messages
>    themselves to say what the client wants to apply DPoP to?
> My initial thought here is no. Take the case of a client working with an
AS that supports DPoP and one RS that does and one RS that doesn't. I can't
really even think what signaling might look like there or how it could be
made to be generally useful.

>    - What if AS and RS don't have a shared support DPoP JWS Algorithm? Do
>    we disqualify such cases or allow for sending two proofs, one for the AS to
>    bind refresh tokens to, one for the RS to bind access tokens to?
> The AS is the one that does the binding (which includes checking the
proof) so I don't see how sending two proofs would really work or help the

_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._