On Wed, May 11, 2022 at 4:53 AM David Waite <da...@alkaline-solutions.com> wrote:
> 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. > Can you elaborate on this? how would two different documents produce the same hash? Regards, Rifaat > 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 > > 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
