Re: [OAUTH-WG] Signed JWK Sets

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 identity
credentials, but it is a great place to develop profiles of identity
credentials that are specific to authorization.

Tldr, I'm supportive of the work, and I'd like to see a COSE format that we
could use in SCITT.

OS

On Wed, Mar 20, 2024, 9:24 AM Joseph Salowey <joe@salowey.net> wrote:

> 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 11:36 AM Watson Ladd <watsonbladd@gmail.com>
> wrote:
>
>> On Sun, Mar 17, 2024 at 5:32 PM Richard Barnes <rlb@ipv.sx> 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
>> here in reality would be based on ECDSA / EdDSA, not RSA, which helps.  I
>> would be comfortable with security considerations recommending that a key
>> pair / certificate used for signing these things be used for no other
>> purpose.
>> >
>>
>
> [Joe] I think there may also be a consideration in some environments that
> problems could arise if keys not intended for signing JWK sets could be
> used to sign JWK sets.
>
>
>> > 2. Validity times are definitely a challenge for the container signing
>> use case, but from the conversations I've had with that community, they are
>> taking an orthogonal approach.  As I tried to sketch in the document, they
>> are establishing authorities that will vouch that a signed thing existed at
>> a given time, so that a relying party can safely rewind their clock and
>> validate as if it were that time.  See, e.g., SigStore <
>> https://www.sigstore.dev/>, which has roughly this shape if you squint
>> right.
>>
>> That should work out: might want a security considerations saying this.
>>
>> >
>> > 3. I don't think there's actually any disconnect between HTTPS
>> authentication and proof of authority.  The Web PKI is about authenticating
>> domain names, which is what both use cases require.
>>
>> Only with certain validation methods. Others like agreed upon change
>> to site content have a narrower scope and the BRs reflect this
>> subtlety. To be honest you're probably safe and I am not the expert
>> here.
>>
>
> [Joe] I think this can work and be useful in many cases, but there may be
> some subtleties here that should be considered.  All the more reason to
> document this.
>
>
>> Sincerely,
>> Watson
>>
>> --
>> Astra mortemque praestare gradatim
>>
>> _______________________________________________
>> 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
>