I’m not sure this is an official call for adoption, but I support this draft. Regardless of the discussion in the other thread, I think this draft has clear value and is well designed. A couple of thoughts:
Presumably it is infeasible for a client to construct a TLS transcript that looks like a valid JWK Set? Ie because we are reusing the TLS cert signing key, I want to check that this doesn’t open up an issue where an attacker interacting with TLS can trick the server into signing a PIKA of their choosing. I’d like to see a security analysis of that.
Are there privacy advantages to using PIKA? It seems like clients not all calling back to the OP to retrieve verification keys would also prevent some tracking? If so, that seems like a good positive to add to the draft.
Best wishes,
Neil On 9 Apr 2024, at 20:33, 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:
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:
(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
|
