I want to voice my support for this draft: Proof of Issuer Key Authority (PIKA). The ability to reason about the past validity of JWKS is extremely useful for using OIDC in signing CI artifacts and e2e encrypted messaging.This includes what we are building at OpenPubkey ( github.com/openpubkey/openpubkey) and also proposed security improvements to software supply chain systems like SigStore ( https://arxiv.org/pdf/2307.08201.pdf).
I want to underscore the value of PIKA to increase the security of JWKS URIs and OpenID Connect. Currently if an attacker compromises an OpenID Provider's JWKS URI the attackers can substitute their own public keys and impersonate any user to any relying parties who depend that OpenID Provider. The effects of Google, Microsoft or Okta's JWKS URI being controlled by a malicious party for even a few minutes could be devastating. The widespread deployment of PIKA would remove this risk and require that attackers compromise not only the JWKS URI but also the PIKA signing keys. As part of the OpenPubkey project, we are planning to write an implementation of PIKA and looking with excitement toward this draft. On Tue, Apr 9, 2024 at 3:33 PM Richard Barnes <r...@ipv.sx> wrote: > 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 <r...@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 >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
