I’m queasy about the interop implications of using a query parameter. Questions then arise like “What if I receive an ni: URI without the query parameter. Should I accept it as valid or reject it?” and “What if the query parameter is
different than the one I expected? Should I accept it or reject it?”
Finally, I believe that defining a particular query parameter would violate the “Get off my lawn” provisions of
https://datatracker.ietf.org/doc/html/rfc7320.
For several reasons, I believe we’re better off staying with the syntax we have.
Best wishes,
-- Mike
From: Rifaat Shekh-Yusef <rifaat.s.ietf@xxxxxxxxx>
Sent: Friday, May 6, 2022 2:28 PM
To: Mike Jones <Michael.Jones@xxxxxxxxxxxxx>
Cc: Manger, James <James.H.Manger=40team.telstra.com@xxxxxxxxxxxxxx>; last-call@xxxxxxxx; draft-ietf-oauth-jwk-thumbprint-uri@xxxxxxxx; oauth-chairs@xxxxxxxx; oauth@xxxxxxxx
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwk-thumbprint-uri-01.txt> (JWK Thumbprint URI) to Proposed Standard
Mike,
RFC6920 defines an optional query parameter, in section 3:
I guess you could have added a query parameter to add that specificity.
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
draft-ietf-oauth-jwk-thumbprint-uri-01 uses labels from the
Named Information IANA registry 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]?
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
[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-call@xxxxxxxx mailing lists by 2022-05-09. Exceptionally, comments may
be sent to iesg@xxxxxxxx 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/oauth
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
