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 On Tue, May 3, 2022 at 10:04 AM Mike Jones <michael.jo...@microsoft.com> wrote: > Hi James. Thanks for your review. > > > > While ni: could have been used, ni: conveys nothing about the hash is of. > Whereas urn:ietf:params:oauth:jwk-thumbprint says that the hash is a JWK > thumbprint. At least for the use cases we anticipate, this additional > specificity adds value. > > > > -- Mike > > > > *From:* last-call <last-call-boun...@ietf.org> *On Behalf Of *Manger, > James > *Sent:* Tuesday, April 26, 2022 9:26 AM > *To:* last-c...@ietf.org > *Cc:* draft-ietf-oauth-jwk-thumbprint-...@ietf.org; oauth-cha...@ietf.org; > oauth@ietf.org > *Subject:* Re: [Last-Call] [OAUTH-WG] Last Call: > <draft-ietf-oauth-jwk-thumbprint-uri-01.txt> (JWK Thumbprint URI) to > Proposed Standard > > > > draft-ietf-oauth-jwk-thumbprint-uri-01 uses labels from the Named > Information IANA registry > <https://www.iana.org/assignments/named-information/named-information.xhtml> > to create URIs from hashes, but then why doesn’t it just use the RFC that > created that registry and already defines a way to format hashes as URIs [RFC > 6920 Naming Things with Hashes > <https://www.rfc-editor.org/rfc/rfc6920.html>]? > > > > For a JSON object representing a JWK whose SHA-256 hash > (base64url-encoded) is NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs: > > - RFC6920 defines the URI: > ni:///sha-256;NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs > - draft-ietf-oauth-jwk-thumbprint-uri-01 defines the URI: > > > urn:ietf:params:oauth:jwk-thumbprint:sha-256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs > > > > -- > > James Manger > > > > > > *From: *OAuth <oauth-boun...@ietf.org> on behalf of The IESG < > iesg-secret...@ietf.org> > *Date: *Tuesday, 26 April 2022 at 7:17 am > *To: *IETF-Announce <ietf-annou...@ietf.org> > *Cc: *draft-ietf-oauth-jwk-thumbprint-...@ietf.org < > draft-ietf-oauth-jwk-thumbprint-...@ietf.org>, oauth-cha...@ietf.org < > oauth-cha...@ietf.org>, oauth@ietf.org <oauth@ietf.org> > *Subject: *[OAUTH-WG] Last Call: > <draft-ietf-oauth-jwk-thumbprint-uri-01.txt> (JWK Thumbprint URI) to > Proposed Standard > > [External Email] This email was sent from outside the organisation – be > cautious, particularly with links and attachments. > > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: - 'JWK Thumbprint URI' > <draft-ietf-oauth-jwk-thumbprint-uri-01.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-c...@ietf.org mailing lists by 2022-05-09. Exceptionally, comments > may > be sent to i...@ietf.org instead. In either case, please retain the > beginning > of the Subject line to allow automated sorting. > > Abstract > > > This specification registers a kind of URI that represents a JSON Web > Key (JWK) Thumbprint value. JWK Thumbprints are defined in RFC 7638. > This enables JWK Thumbprints to be used, for instance, as key > identifiers in contexts requiring URIs. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwk-thumbprint-uri/ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > 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
