Re: [OAUTH-WG] Signed JWK Sets

Richard Barnes <rlb@ipv.sx> Tue, 09 April 2024 19:32 UTC

Return-Path: <rlb@ipv.sx>
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 464DCC14F70B for <oauth@ietfa.amsl.com>; Tue, 9 Apr 2024 12:32:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTz1OOzMtJG4 for <oauth@ietfa.amsl.com>; Tue, 9 Apr 2024 12:32:47 -0700 (PDT)
Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60044C14F6FC for <oauth@ietf.org>; Tue, 9 Apr 2024 12:32:47 -0700 (PDT)
Received: by mail-il1-x134.google.com with SMTP id e9e14a558f8ab-369e3c29aedso27910645ab.1 for <oauth@ietf.org>; Tue, 09 Apr 2024 12:32:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20230601.gappssmtp.com; s=20230601; t=1712691166; x=1713295966; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=r6mfzD6T7foJJDybbBMcSFd1/6+bZv2hy08ic0+fuPk=; b=SFT0W0TvJ0cOQwxY6Hj72DPdAT+G+4WzwH6j/ScUpBqFYWTiZIhJAbDmDBrhXWE28j kUvvSbOlvTh9hxWeFATvut44gS19Jk6mRaN743YbY42uiq8y0DP2QZZP3yd1AlixKWfZ lLqgX6PWM62kegrNzBUh9s5AbzTe/kxJcIdomEVkm1P0L6edeE8yOg7fZisSmnqMBCLe y876/+jO/7ye7hKrB7cR3h7G8vgbjRIn1P9wurOu7z+32gJvz6QFpjFUUONT86tHhzAz FiTADKrUruAGrQKeGu8lVw5Kr875080WfVrqhT/8XvfS3EOPP9F4ifB5HSzNdYLxCczO /IgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712691166; x=1713295966; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=r6mfzD6T7foJJDybbBMcSFd1/6+bZv2hy08ic0+fuPk=; b=sROJiFE1Znf8X3W2kPhcpbxB40BBfdhK4rYdtVoQsRrwW+/TkZ3ImGqLHS3IZBjZAB s0cetSI9r3Vdjsq0jXkdZPbGeGphwF5QjLvhtUhOKmBU+JOk2r1U0ecJPOzzOmU7pxHc U7mryvRMfgIPm/8jBg5rQjlcW0HPuvfbi6mZeMAfvc0jMraVLA5L0/LgACum1Mok92+3 0r5Qao95tvOBPocqJEGHZvDhXTwtLxjoOFwRLSyR3Kg8FfT4mwoqMpvFhbmJX8jfX+3t X+jDCN3CKLkbrhW1Akuzh2lw1pzmbQ0LRsBCLSZ65Ci+Wc+UrIlcvqDZjRjRe/kSeNx6 lDHw==
X-Gm-Message-State: AOJu0Ywhor2LvllvLDoYdB53qrC+LOaUXvKWDniBbX2BQr0wJzWBQ+67 c3yGXgohLMALqSUa2lNrSbgYVFilh09D8qHJNdDKHZnUflgm7DomQ24l9Q+Av0maBqXt5jEDsk/ Rqg0ocXJuCwyO/1LMoaAg6pWa6MQ6v1uxxbzSLwCGcH2wvJZ+u+o=
X-Google-Smtp-Source: AGHT+IHrapEOF0Oo93Lsd2RItzWWFnvI207ln2EO+GsYFdVs4AIO3fsqaKQ7MHYEX4UdTS8x2eO4zydj0wHC2tvsCp8=
X-Received: by 2002:a05:6e02:12c6:b0:36a:1dc2:8d43 with SMTP id i6-20020a056e0212c600b0036a1dc28d43mr862388ilm.25.1712691166047; Tue, 09 Apr 2024 12:32:46 -0700 (PDT)
MIME-Version: 1.0
References: <CAL02cgSANrR=nys3RXDOYJPibLkv25X8Okq4dhL0Dpfi_ZSS_A@mail.gmail.com>
In-Reply-To: <CAL02cgSANrR=nys3RXDOYJPibLkv25X8Okq4dhL0Dpfi_ZSS_A@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Tue, 09 Apr 2024 15:32:27 -0400
Message-ID: <CAL02cgQG4Fhn2zCmq0EFLJReB_jf257msdM9OEgYr03n6D1qRg@mail.gmail.com>
To: "oauth@ietf.org WG" <oauth@ietf.org>
Cc: Sharon Goldberg <goldbe@bastionzero.com>
Content-Type: multipart/alternative; boundary="0000000000009041f80615aefc2a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/9yxcol9gb60rrsJy2Rq6vR4cE7E>
Subject: Re: [OAUTH-WG] Signed JWK Sets
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 09 Apr 2024 19:32:51 -0000

Hi all,

Thanks for all the feedback on-list and at IETF 119.  Sharon and I took a
second pass at this idea and actually made an Internet-Draft this time:

https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/

The new draft is focused on "Proofs of Issuer Key Authority".  This new
framing is based on a couple of important bits of feedback from Mike Jones,
(1) that OpenID Federation had already defined most of what we need, and
(2) that it would help to be clear that the real focus here was on
replacing HTTPS with JWT as the proof that a key is authoritative for a
given issuer.  Given that, we reuse the "historical JWK set" format from
OpenID Federation, and of course, focus on the "key authority" issue.

Obviously, more feedback is welcome, but especially on whether this would
be a good thing for the OAuth WG to work on.

Thanks,
--Richard


On Sun, Mar 17, 2024 at 1:55 AM Richard Barnes <rlb@ipv.sx> wrote:

> Hi all,
>
> A few of us have been considering use cases for JWTs related to Verifiable
> Credentials and container signing, which require better "proof of
> authority" for JWT signing keys.  Sharon Goldberg and I wrote up a quick
> specification for how to sign a JWK set, and how you might extend discovery
> mechanisms to present such a signed JWK set:
>
>
> https://github.com/bifurcation/redistributable-jwks/blob/main/draft-barnes-oauth-redistributable-jwks.md
>
> (Just in GitHub for now; will publish as an I-D when the window reopens
> tomorrow.)
>
> If we could get this functionality added to OAuth / OIDC, it would make
> these use cases work a lot better.  As a prelude toward proposing working
> group adoption, it would be great to know if this design seems helpful to
> other folks as well.  Obviously, happy to answer any questions / comments.
>
> Thanks,
> --Richard
>