Bo, the newly published version of
https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/
incorporates the changes to address your review comments.
Thanks again!
-- Mike
-----Original Message-----
From: Michael Jones
Sent: Wednesday, September 11, 2024 4:07 PM
To: Bo Wu <[email protected]>; [email protected]
Cc: [email protected]; [email protected];
[email protected]; Deb Cooley <[email protected]>
Subject: RE: Opsdir last call review of draft-ietf-oauth-resource-metadata-08
Bo, your review comments are addressed in
https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/pull/51/commits/699182c7c4d6c4e06e99c1463ae51a18cc64f4fa,
which is part of
https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/pull/51, and
https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/commit/fe6fd613eae34e3c63acbec340d21de21a3a1176,
which adds sequence numbers to the diagram.
Thanks again!
-- Mike
-----Original Message-----
From: Michael Jones <[email protected]>
Sent: Tuesday, September 10, 2024 7:26 PM
To: Bo Wu <[email protected]>; [email protected]
Cc: [email protected]; [email protected];
[email protected]; Deb Cooley <[email protected]>
Subject: RE: Opsdir last call review of draft-ietf-oauth-resource-metadata-08
Thanks for your review, Bo. My replies are inline below, prefixed by "Mike>".
-----Original Message-----
From: Bo Wu via Datatracker <[email protected]>
Sent: Thursday, August 29, 2024 5:53 AM
To: [email protected]
Cc: [email protected]; [email protected];
[email protected]
Subject: Opsdir last call review of draft-ietf-oauth-resource-metadata-08
Reviewer: Bo Wu
Review result: Has Nits
Hi,
I'm the assigned Ops reviewer. I think this document is ready with nits.
Here are some nits and questions:
nits:
1)
The Figure 1 Sequence Diagram does not seem to match the text in the steps.
For example, step 5 in the diagram corresponds to step 5 and the first half of
step 6 in the text description, and there is no "user agent" (step 8) in the
diagram. Therefore, it is recommended that sequence numbers be added to the
diagram.
Mike> I'll plan to work with Aaron Parecki to add numbers to the diagram, if
possible. (It may be tricky, because there are both SVG
https://drafts.oauth.net/draft-ietf-oauth-resource-metadata/draft-ietf-oauth-resource-metadata.html#name-sequence-diagram
and ASCII ART
https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-08.txt
versions of the diagram.) This issue is tracked at
https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/issues/49.
2)
s/The resource value returned/The "resource" value returned
Mike> In both cases, the word "resource" is in a fixed-width font as a result
of denoting it as <spanx style="verb">resource</spanx> in the XML source (which
will be transformed to <tt>resource</tt> in the XML2RFC v3 source) to mark it
as being a protocol element. In xml2rfc v1 this would have resulted a fixed
width font in the HTML output and "resource" in the .txt output, but the newer
tooling omits the double quotes in the .txt output for some reason. I'm prone
to go with the choices made by the IETF's tooling and not manually add the
double quotes.
3)
s/specific member names such as resource/specific member names such as
"resource"
Mike> Same situation. "resource" here is already in a fixed-width font because
its source is <spanx style="verb">resource</spanx>.
Some questions:
1)
Section 1 Introduction
The metadata for a protected resource is retrieved from a well-known
location as a JSON [RFC8259] document, which declares information
about its capabilities and optionally, its relationships to other
services.
Do other services refer to authorization servers? If yes, then it is
recommended to use authorization servers directly.
Mike> Yes, the metadata for Authorization Servers is also retrieved from a
well-known URL, as described at
https://www.rfc-editor.org/rfc/rfc8414.html#section-3. This specification
follows that pattern. The "authorization_servers" value is a set of AS issuer
identifiers, as defined in RFC 8414. That enables retrieving their metadata in
that way.
2)
Section 1 Introduction
The means by which the client obtains the location of the protected resource is
out of scope. In some cases, the location may be manually configured into the
client.
In Section 5.3, there is also text：
This specification is intended to be deployed in scenarios where the
client has no prior knowledge about the resource server,
It seems that text in Introduction means that the resource server is prior
knowledge of the client if I understand correctly. Am I correct?
Mike> Actually, the client may learn about the resource server at runtime as a
result of user interface actions by the person using the client. The client
might be, for instance, an e-mail reader and the resource might be an e-mail
server. The client can be pointed at any of thousands of e-mail servers
worldwide, which would be the resources.
Aaron Parecki did a good job explaining that motivating use case several IETFs
ago. I'll try to dig that up and we'll consider describing it in the draft.
3)
Section 1.2. Terminology
Resource Identifier:
The Protected resource's resource identifier, which is a URL that uses the
https scheme and has no query or fragment components.
Protected resource metadata is published at a .well-known location [RFC8615]
derived from this resource identifier, as described in Section 3.
resource
REQUIRED. The protected resource's resource identifier, which is a URL that
uses the https scheme and has no query or fragment components. Using these
well-known resources is described in Section 3.
The two descriptions look almost same. Perhaps the reference of the definition
can be used, for example:
Resource Identifier:
The Protected resource's resource identifier, which is a URL (see Section 2).
Mike> I agree that adding the reference makes sense.
4)
Section 5.3 Client Identifier and Client Authentication
There are some existing methods by which an unrecognized client can make use of
an authorization server, such as using Dynamic Client Registration [RFC7591] to
register the client prior to initiating the authorization flow. Future
extensions might define alternatives, such as using URLs to identify clients.
On “Future extensions",does this mean the extensions of RFC 7591?
Mike> Good point. We mean future extensions to OAuth. I'll clarify in the
draft.
Thanks,
Bo Wu
Thanks again for your useful review!
-- Mike
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
