Hi there,
FWIW, this is a really interesting proposal, and I recognise the use case
in 1.2. Use Case: Verifying Stored Signature.
>From a Docker perspective, being able to sign attestations on container
images using workload identity (i.g. GitHub) using something like
OpenPubkey
Just to be clear, this is *not* a call for adoption at this time.
So, please focus on discussing the concept described in this individual
draft.
Regards,
Rifaat
On Wed, Apr 17, 2024 at 1:43 PM John Zila wrote:
> On 11 Apr 2024, at 21:15, Neil Madden wrote:
>
> > I'm still digesting this
On 11 Apr 2024, at 21:15, Neil Madden wrote:
> I'm still digesting this draft, and generally supportive of it. However,
I don't think it stops the attack you mention here, which sounds similar to
threats that Ryan Sleevi discussed for FastFed in [1]. Essentially, in the
current OIDC model, an
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
> On 12 Apr 2024, at 03:16, Ethan Heilman wrote:
>
>
> Hi Neil,
>
> I agree that PIKA would not protect against an attacker compromising a JWKS
> URI via a mis-issued TLS cert.
>
> I was thinking of a simpler attack where the attacker compromises the server
> where a JWKS URI is hosted
The mechanism in the draft provides some separation between the trust
establishment and distribution which is useful. This is definitely
applicable to the use cases described in the draft and I agree with Ethan
that it can help in other areas as well depending upon how things are
deployed. I
Hi Neil,
I agree that PIKA would not protect against an attacker compromising a JWKS
URI via a mis-issued TLS cert.
I was thinking of a simpler attack where the attacker compromises the
server where a JWKS URI is hosted or the JWKS is stored. For instance
consider an JWKS which is read from a
On 11 Apr 2024, at 01:12, Ethan Heilman wrote:
>
> 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
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 (
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
In SPICE and SCITT, we have discussed similar proposals for "identity
documents", which are essentially a signed collection of keys and
attributes.
I think a generic building block that works for JOSE and COSE would be
great.
I don't think OAuth is the right place to develop general purpose
I think Signed JWK sets are useful and would like to see them used in more
use cases so separating out the specifications seems like a good idea. We
will have to be careful specify what security and deployment properties you
are trying to achieve in different use cases.
On Tue, Mar 19, 2024 at
On Sun, Mar 17, 2024 at 5:32 PM Richard Barnes wrote:
>
> Hi Watson,
>
> I appreciate the concerns with regard to re-using Web PKI certs for cases
> such as these. Care is required, but I think there is a path here.
>
> 1. Clearly there are cross-protocol concerns. I expect that most usage
et/specs/openid-federation-1_0.html#section-16.8, which
> can be used to indicate key expiration time, etc.
>
>
>
> *From:* Michael Jones
> *Sent:* Sunday, March 17, 2024 7:00 PM
> *To:* Richard Barnes ; oauth@ietf.org WG
> *Cc:* Sharon Goldberg
> *Subject:* RE: [OAUTH
Hi Watson,
I appreciate the concerns with regard to re-using Web PKI certs for cases
such as these. Care is required, but I think there is a path here.
1. Clearly there are cross-protocol concerns. I expect that most usage
here in reality would be based on ECDSA / EdDSA, not RSA, which helps.
On Sat, Mar 16, 2024 at 10:56 PM Richard Barnes 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
Subject: RE: [OAUTH-WG] Signed JWK Sets
Signed JWK Sets are part of the OpenID Federation specification and are in
production use. For instance, see
https://openid.net/specs/openid-federation-1_0.html#name-metadata-extensions-for-jwk
and the "keys" registration at
https://openid.net/sp
-- Mike
From: OAuth On Behalf Of Richard Barnes
Sent: Sunday, March 17, 2024 3:55 PM
To: oauth@ietf.org WG
Cc: Sharon Goldberg
Subject: [OAUTH-WG] Signed JWK Sets
Hi all,
A few of us have been considering use cases for JWTs related to Verifiable
Credentials and container signing, which requ
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
19 matches
Mail list logo
