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 <j...@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 <watsonbl...@gmail.com> > wrote: > >> On Sun, Mar 17, 2024 at 5:32 PM Richard Barnes <r...@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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
