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

Francis Pouatcha <fpo@adorsys.de> Sun, 07 June 2020 14:00 UTC

Return-Path: <fpo@adorsys.de>
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 29F133A0878 for <oauth@ietfa.amsl.com>; Sun, 7 Jun 2020 07:00:23 -0700 (PDT)
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 (1024-bit key) header.d=adorsys.de
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 eyxifJ9Ps7Ma for <oauth@ietfa.amsl.com>; Sun, 7 Jun 2020 07:00:20 -0700 (PDT)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 104583A0873 for <oauth@ietf.org>; Sun, 7 Jun 2020 07:00:20 -0700 (PDT)
Received: by mail-wm1-x333.google.com with SMTP id f185so13819177wmf.3 for <oauth@ietf.org>; Sun, 07 Jun 2020 07:00:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NnHpR913E4ho1yLRfW1pmUmOKC/+pEGUXzV2ldKuxVo=; b=ICIGOC3Rf/RfR5er2Bp7aBCiKQjIKLOk0ww5GgVhURXzX0EfRzOJ+CGWJGCtJ6HV+u mj9ak0t0m5ic4tEiXsAahhScodEcxLQv5NSrSE6higM9NyUrOSbwRuMdgI7sHw9U96ip wG7sphKgrQVPpqbmLa1YyEriI5Oy/qaimsh9o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NnHpR913E4ho1yLRfW1pmUmOKC/+pEGUXzV2ldKuxVo=; b=tVj/s6ny2w4g5TGkL2D7nkbN4zxdACrhY8BnE8CJSfKpZwptdfu2PQgeyx2ARMKfxz R/qOsBfP7ffGSvLURtnd1AIEJiACxr+/1eFPmHgazWQwk0RU7iHGdGvhDhkPss8XcObv 7OjZ2NHLjbUfqiZLbkBxvqtGSp/9JpGBiJXOkvP9yDqyvWe+d64VV4OHqMyZ+xlpxfSz TIm0SfsGsud37Ke9EUrE49f4N+acEOe830i5RX8PLrs/cmBuJyy4C2sx6zPnY4hc1JRL T/nNz0oOXkWqJAo3IVrUeoNTUyTKPppB4n00bM3QtO2diEWB3Go3gJR7QZop03ha4Eu5 saXA==
X-Gm-Message-State: AOAM531t3VBKIHfu6/BLqnrJrAiEQVugfEqVMonYY52TH8MzDkYUzaAf RAu7efjvFsXP/+c1gPeS4kj0FMZgShyqGp8cFddOdg==
X-Google-Smtp-Source: ABdhPJxXNLiIj6C0qXygCi+qHF+cgmHRyF930ylQihF8Kdh6OgstzTIGBhXO44LESdhLWn0F2m2oG7jGu73PnCPTGQU=
X-Received: by 2002:a1c:ed0e:: with SMTP id l14mr11748364wmh.8.1591538416913; Sun, 07 Jun 2020 07:00:16 -0700 (PDT)
MIME-Version: 1.0
References: <375FA230-5700-42A5-B933-2A37D296BCDF@forgerock.com> <AC87697A-07BC-43E6-82C3-73892A7C505D@gmail.com> <BB604649-B01B-460B-B312-126600CD69DE@gmail.com>
In-Reply-To: <BB604649-B01B-460B-B312-126600CD69DE@gmail.com>
From: Francis Pouatcha <fpo@adorsys.de>
Date: Sun, 7 Jun 2020 10:00:06 -0400
Message-ID: <CAOW4vyOL0ZTZKpMghVLEmFmaaBq+nZCZ1b8KPZKetsa9c=fPnw@mail.gmail.com>
To: Nov Matake <matake@gmail.com>
Cc: Neil Madden <neil.madden@forgerock.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fc9e5105a77ee972"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/t2sr-HM0uREtBEuBse3aI-_h2q0>
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 14:00:23 -0000

I am a little bit confused. Let me  break it down:

code :
  -> sender : Client
  -> consumer : AS
  -> sender PoP :
       --> confidential client: code_verifier (PKCE)
       --> public client:  code_verifier (PKCE)?

refresh_token :
  -> sender : Client
  -> consumer : AS
  -> sender PoP :
       --> confidential client: private_key_jwt, mTLS
       --> public client:  DPoP?

access_token :
  -> presenter : Client
  -> consumer : RS
  -> sender PoP :
       --> confidential client: private_key_jwt, mTLS
       --> public client:  DPoP?

Is this correct?

On Sun, Jun 7, 2020 at 8:42 AM Nov Matake <matake@gmail.com> wrote:

> * sender-constrained code, bearer access token and sender-constrained
> refresh token, use DynReg or "PKCE + DPoP allowing access token remaining
> bearer".
> * sender-constrained code, sender-constrained access token and
> sender-constrained refresh token, use "DynReg + DPoP" or "PKCE + DPoP".
> * bearer code, sender-constrained access token and sender-constrained
> refresh token, use DPoP only.
> * sender-constrained code, bearer access token and bearer refresh token,
> use PKCE only.
> * bearer code, bearer access token and bearer refresh token, use none of
> them.
>
> 2020/06/07 21:36、Nov Matake <matake@gmail.com>のメールt;のメール:
>
> 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
>
>

-- 
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/