RFC 7517 does define an "application/jwk+json" media type which could be used with the ct= query parameter for ni-scheme uri. The resulting ni-scheme URI could be used to refer to a specific generated JWK document.
However, I do not believe this would be a sufficient way to indicate that this is the pre-hash minimized, canonicalized form required for thumbprint generation in RFC 7638 (e.g. non-required members removed, JSON documents in lexicographical key order represented as UTF-8). The information dropping of the canonicalization in JWK thumbprints results in a few important properties - in particular, a local JWK document representing a private key and the shared JWK document representing the corresponding public key will have the same thumbprint. This enables the JWK Thumbprint to serve as an algorithmic key identifier for all participating parties. This creates the issue with using the ni scheme - a NI URI could be used to refer to a single JWK document. However, the semantics when interpreting a thumbprint are that it references potentially multiple data forms with different binary representations, and that a software ‘lookup’ operation taking a JWK thumbprint may result in data which does not have the specified hash value. My interpretation would be that these behaviors go against the spirit of RFC 6920. -DW > On May 6, 2022, at 6:27 AM, Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> > wrote: > > Mike, > > RFC6920 defines an optional query parameter, in section 3: > https://www.rfc-editor.org/rfc/rfc6920.html#section-3 > <https://www.rfc-editor.org/rfc/rfc6920.html#section-3> > > I guess you could have added a query parameter to add that specificity. > > Regards, > Rifaat
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
