Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature
Warren Parad <wparad@rhosys.ch> Wed, 13 October 2021 19:01 UTC
Return-Path: <wparad@rhosys.ch>
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 43F933A0BB9 for <oauth@ietfa.amsl.com>; Wed, 13 Oct 2021 12:01:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch
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 KGqmhIEhkYmE for <oauth@ietfa.amsl.com>; Wed, 13 Oct 2021 12:01:20 -0700 (PDT)
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 09CB53A0A08 for <oauth@ietf.org>; Wed, 13 Oct 2021 12:01:17 -0700 (PDT)
Received: by mail-yb1-xb31.google.com with SMTP id s4so8818203ybs.8 for <oauth@ietf.org>; Wed, 13 Oct 2021 12:01:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1t5M+V09lOjyZlY2zQc6t+9YDFaltulaKRU0ITRDJfs=; b=RoaLzuIdHaJs5qAkECOIkFRZklFsBdxI6GVRTqfK09ozL8HSDm/u3HO1AFaST74mYG SJB/ZGL/OGYqtvW4vYFIzoBEOklNylL9sENkuixu2DdM7IZgRTwxsRorB2xZQUA+6+dx 8PZNatQNAQfvfSIM9gyzNbDwTVMsmC19yOqoXzA/TgH1prBIaVuOrTHGs9qprZa5nM63 Fdhun4RS70vx2wxaqovgpnSoSHa9EGcLICWEXbZDxmYt3VFZVzL7yyl7DZArBUrrJ/d/ DOem+YDjN++PrGcZTzsVl1AwEevsqWTTkdYyp8YQl/EhUiUkCFuNXInquZSaKwbWYudE ZAJA==
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=1t5M+V09lOjyZlY2zQc6t+9YDFaltulaKRU0ITRDJfs=; b=bwpW0UQb2BTRTdoKbWlN+KYIvTZgXpRv4N0Q8W1tVHkugD1Yf2hZygcRzYsubTjP/E qFxsPIswb0YBEEIFgil/95G7ve9DqCXbNIGNnG6BwkBr/OFlVE3UqIidboashdoYu7QZ hUgYkljHHnXYVKgt7pGDR8TgHaiaeZUsR9j+1DAGjwNaU2I28XTAmiP9xLv5nyBdxDcq H4pL7SXStD9KXL4b4LcIf+kesHCfCmz//Ahmf6PiQblLXK6FkrgyYuhhwIis9fxNUdoR w/az9XOuI1WleVhahLM1xK1igmuxFcilWQma7acfyq2BpBRch+xl6HfCuSyEie/2N8h+ hlSg==
X-Gm-Message-State: AOAM531BE0iHKrZtapqoLnLAcrZy2hAfRXZHcQU4xaVwW/vi3+O2MbTc LpdRbx42iOJWCAXtPd/l19WpWoUvM/Luuvf8wyaVfZOpx3O2Moc=
X-Google-Smtp-Source: ABdhPJwLBhc4oREIyXdQ72j7/aR/L+NLAWjb0RTvREbSAjePRj5lk8N87Qt3qr4KqyvxjlbrYSxaw6Ez3iQJ/AWQeC4=
X-Received: by 2002:a25:dc82:: with SMTP id y124mr1199089ybe.521.1634151676909; Wed, 13 Oct 2021 12:01:16 -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>
In-Reply-To: <7618AC29-8221-4FC0-BCF3-199C6BA96FE5@alkaline-solutions.com>
From: Warren Parad <wparad@rhosys.ch>
Date: Wed, 13 Oct 2021 21:01:06 +0200
Message-ID: <CAJot-L2ztfruwe3L=uQuCYoZ++NTbejv_r3GOL4546q0nOTQPA@mail.gmail.com>
To: David Waite <david=40alkaline-solutions.com@dmarc.ietf.org>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000362e9c05ce409662"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/mIE9ssaO-1Mgs7c2YOdJA6iXNyc>
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: Wed, 13 Oct 2021 19:01:44 -0000
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 would agree with keeping DPoP simple if it meant that 99% of problems were solved, in which case the question would be why do we need this RFC, and if what is here is so common, then what good is the DPoP one? Simple is useless if it is never used. If there are really so many cases, then I think we need to focus on recreating PoP in an extensible way that allows the DPoP to sit on top, and other RFCs to be layered in without a bunch of RFCs to all have competing semantics. Here's a great example. I think having an additional header is unjustified, DPoP, Signature, or whatever you want to call it. But the only thing more unjustified than that is having different headers for different implementations of PoP. We can start with a new Draft that just says, PoP header is X, end of story, might as well call it *Authorization-Extra-Info*, and then layer in what you want in there. Then the number of differences through these refactoring between these two drafts becomes smaller. Surely we can agree to a draft that contains only the semantics that are the same between the existing two, and then reuse the same terminology and the same implementation, header name, etc... We definitely need a PoP RFC, there's no question there (at least I don't think there is), so let's start with the subset of all pieces that both sets of authors can agree to. Is this the list of current concerning limitations? > > 1. Does not support symmetric keys. > 2. Requires the same key to be used with AS and RSes. > 3. Does not support multiple valid signing keys. > 4. Signed content is copied into the JWT and therefore duplicated > within the message. This allows for bugs where the verifier fails to check > that these values match, or performs that check incorrectly. (e.g., > assuming case insensitivity) > 5. Only covers the method, scheme, host, and path. Allows for > additional arbitrary content to be signed, but does not provide any > guidance or support for defining interoperable extensions. > 6. Depends on JWT, which may be a new dependency, particularly for > clients that are doing OAuth 2.0 but not OIDC. > > Can we narrow this down to the non-negotiables? For instance surely (1), (4), (6) aren't that bad, sure they may not be optimal for every case. I can (2) & (3) to be actually limiting and (5) to be easy to allow extensibility. Would your concerns be at least somewhat be mitigated by allowing for solutions regarding (2) & (3)? Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Wed, Oct 13, 2021 at 8:41 PM David Waite <david= 40alkaline-solutions.com@dmarc.ietf.org> wrote: > > > > On Oct 13, 2021, at 12:26 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > > > Those issues that could be addressed without completely redesigning DPoP > have been discussed within the Working Group multiple times. (See quotes > and meeting notes references in my previous message) The authors have > pushed back on extending DPoP to cover additional use cases them due to a > desire to keep DPoP simple and lightweight. I don't begrudge them that. I > think it's reasonable to have a "dirt simple" solution, particularly for > SPAs given the relative limitations of the browser environment. > > > > Other issues are inherent to fundamental design choices, such as the use > of JWS to prove possession of the key. E.g., you cannot avoid the data > duplication issue since a JWS signature only covers a specific > serialization of the JWT header and body. > > Agreed with keeping DPoP simple, which was why I was asking if the > proposal could indicate it was targeting some of these other use cases. The > current draft being proposed for adoption I believe is fixed to the same > HTTP properties that DPoP leverages, and thus appears to be targeting the > same use cases with a different proof expression. > > The duplication within the token is also a trade-off: it allows an > implementation to have a white list of acceptable internal values, if say > the host and path are rewritten by reverse proxies. It also allows an > implementation to give richer diagnostic information when receiving > unacceptable DPoP tokens, which may very well come at runtime from an > independently-operating portion of an organization reconfiguring > intermediaries. > > -DW
- [OAUTH-WG] Call for Adoption - OAuth Proof of Pos… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Aaron Parecki
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Dick Hardt
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Justin Richer
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Justin Richer
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Dick Hardt
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Justin Richer
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Aaron Parecki
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Dick Hardt
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Denis
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Warren Parad
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Neil Madden
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Ash Narayanan
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Aaron Parecki
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Richard Backman, Annabelle
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Mike Jones
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Richard Backman, Annabelle
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Justin Richer
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Richard Backman, Annabelle
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Domingos Creado
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Dick Hardt
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Dick Hardt
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Mike Jones
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Richard Backman, Annabelle
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Warren Parad
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Richard Backman, Annabelle
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Richard Backman, Annabelle
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Dick Hardt
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Warren Parad
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… David Waite
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Richard Backman, Annabelle
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Warren Parad
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: Call for A… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adopt… David Waite
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adopt… Warren Parad
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… David Waite
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Warren Parad
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: Call for A… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adopt… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adopt… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adopt… Warren Parad
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adopt… Justin Richer
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Justin Richer
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Warren Parad
- Re: [OAUTH-WG] Call for Adoption - OAuth Proof of… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adopt… Dick Hardt
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adopt… Justin Richer
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adopt… Dick Hardt