Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

Dick Hardt <dick.hardt@gmail.com> Fri, 22 October 2021 22:09 UTC

Return-Path: <dick.hardt@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 4793B3A0888 for <oauth@ietfa.amsl.com>; Fri, 22 Oct 2021 15:09:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.468
X-Spam-Level:
X-Spam-Status: No, score=-0.468 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_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 1-UsVZrRLL-8 for <oauth@ietfa.amsl.com>; Fri, 22 Oct 2021 15:09:18 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 D49943A087C for <oauth@ietf.org>; Fri, 22 Oct 2021 15:09:17 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id o26so1415154ljj.2 for <oauth@ietf.org>; Fri, 22 Oct 2021 15:09:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CdfbcrqF4TZP+Nl6TYJp0S98UOd9R4kVsDXhkaL5Sa4=; b=eXQTgm09t5Aev2S72cJFu4iPhK6M/4hZ6JVZU8RxxCgT9sZI8lVz3AGeIxosUbmgvQ v75phhY21kDAEZdjSHOmE4ntr1H2MlpRTc1gwh0QVf9mmiDdk4xJGwY0QdM5ELSEl2XT n4pQ1FBMoLT0TrKfn7ny/7IDlSWfkNTKcqkeh3oYWc406sRpXSxkmdxFxogQzVZH6w88 YD5NZDBu96MgBCyap/lVF1eMnaIaZhY1E2ldFEO6OE4dhwK43KJiz9hr2OTkZKx0YOff KIM4f7XLLaKHTt91SxLFF/chpryqlavJGJ82RtPEedA6ReZZJ8IgpXt5QYnaDFy+39nc yAvA==
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=CdfbcrqF4TZP+Nl6TYJp0S98UOd9R4kVsDXhkaL5Sa4=; b=tSb2wR3xnLVvoLMYxlqZLpw8ncrfRh7Y9iOfODN6Ci0hdr1HehYsq690ScKZJX1fE+ Vo1dno9AMeUXIb01CDsTqdbxMuIDwsNE0EBNRH3Wwom0cMM1t+RyWs1dG4/oPRFE/IJY mqaKUN4O5X/LJegA9yZCNwCChyxGidCT3a3U844J16f2w7Kly9WH0v7JOB2x6+cPglQW Y0dcc0LlfrPfAl5Mi49Jo7b8aGcLDdEAf2CfWL5a0eZQitjm0v6SlYHOWLHZpvDhrEDb 1bImc1bmKf54YoptyBz5izpD9p7vbS1Zl36d0+r4AjElCtrGA8kifWOdGehN/8G77V/B 3qyQ==
X-Gm-Message-State: AOAM533xVObydukvTRLG6JexaZjNDrZhFB8NBjGLEWZI8oVb7Z0HA+Cy Pd6W9K33wE0g90mQ2vHI+F20JA7bZwMiJS0/GAc=
X-Google-Smtp-Source: ABdhPJylE9cWWpjMRAVu2Hq7dfakSFSmFbkFREEuferwxFB95RqNFOFOVaIdj2+Befzx0vMIC4+teuN+bPXNO4N8xNg=
X-Received: by 2002:a2e:a407:: with SMTP id p7mr2721431ljn.68.1634940550154; Fri, 22 Oct 2021 15:09:10 -0700 (PDT)
MIME-Version: 1.0
References: <CADNypP9QXCEjJmkhBvTHn68kDcJ2Mfg-tSQx1-hvfPoOTXCKzA@mail.gmail.com> <CAGBSGjqasD=eYnsMm7gZB2g+=C4abZoVi7FH4e7EFfgwKdjS8w@mail.gmail.com> <CAD9ie-uH9xGL9orTFxEd=tfhO6Q-S3sDHrQDtU7h0_dr6YeLOg@mail.gmail.com> <EE56CE99-5592-40AF-9BA5-7F3886ED315A@mit.edu> <CAD9ie-t9i1sVLhVhJp-mWSchV_x0b3no7i4qNXvcaQS+8OqCVA@mail.gmail.com> <CAGBSGjrgVbGWwFq6LDX_2Vhv7yQkwtEEjy36GpLj-bN+MtcX-w@mail.gmail.com> <CAD9ie-vJiwBSV71z4_2TJJO7A52mV763XvXmEPsEFgOMFVOwyQ@mail.gmail.com> <D445073E-D495-4250-9773-9AEEB09C01E0@amazon.com> <CAD9ie-t5EBZLtHmmbDQu9iq-d87gf07X5Fes_ZqFts5hDCOOuw@mail.gmail.com> <A312C403-3341-4B29-AEB3-B547E9A802E7@amazon.com> <CAD9ie-sW537PEzavzv1v6JSOFSfLa7iRVPAXD-miuEY8GMmDeQ@mail.gmail.com> <CAJot-L1fio+-1sSn6Z88ianq04RoHJ3M5yxe0Bzu2Cs-CWCPkg@mail.gmail.com> <54A59064-B40B-4F6C-9E7C-A5618C2C4D3E@alkaline-solutions.com> <3CAB48B9-B517-4693-8CBB-3377122A6077@amazon.com> <CAJot-L3CiPf0XbTRHPgs71cxfhr2626+vt4XELDSf5nhkj8wdg@mail.gmail.com> <EB86A178-052C-48CD-9F99-63B9173DF7B0@amazon.com> <7618AC29-8221-4FC0-BCF3-199C6BA96FE5@alkaline-solutions.com> <CAJot-L2ztfruwe3L=uQuCYoZ++NTbejv_r3GOL4546q0nOTQPA@mail.gmail.com> <E8AB2162-98DE-452E-A64B-0BCCDC36CECD@amazon.com>
In-Reply-To: <E8AB2162-98DE-452E-A64B-0BCCDC36CECD@amazon.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Fri, 22 Oct 2021 15:08:33 -0700
Message-ID: <CAD9ie-vrYO+n36Eig28NqfVw0kK6STKYs9MUKY66YGZFR-QKeQ@mail.gmail.com>
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Cc: Warren Parad <wparad@rhosys.ch>, David Waite <david=40alkaline-solutions.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b88e2205cef84209"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/arYdxvhdYlFcHlvkJItwK2K5LmU>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature
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: Fri, 22 Oct 2021 22:09:23 -0000

I have a use case for a self contained request that can be
independently verified by multiple parties. IE, not just have PoP at HTTP
endpoint, but by components doing processing further down the line. It also
provides non-repudiation.

For example, a JWT that is sent as an HTTP payload includes the request and
the access token.

mTLS, DPoP, and HTTP signing don't provide this functionality

It is not clear if others have similar requirements, or if there is value
in standardization effort, but I wanted to call out a use case not solved
by the current efforts.

/Dick

On Wed, Oct 13, 2021 at 2:55 PM Richard Backman, Annabelle <richanna=
40amazon.com@dmarc.ietf.org> wrote:

> If keeping DPoP simple means we have to have come up with 10 different
> variants to handle all the different cases that it doesn't support, then it
> isn't keeping it simple, it is just pushing the problem forward to the
> implementers to figure out which set of RFCs to implement.
>
>
> I'm hoping we can stop at 3: mTLS, DPoP, and Justin's draft. If someone
> has use cases that aren't covered by one or more of those, they should
> bring those up so we can discuss them and decide what changes are
> warranted. (Either here, or in HTTPbis if changes should be made to Message
> Signatures) My preference would've been to stop at 2, but the consensus has
> not been in favor of expanding the scope of use cases served by DPoP.
>
> ᐧ