[Ace] Éric Vyncke's No Objection on draft-ietf-ace-oauth-authz-38: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-ace-oauth-authz-38: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. I have really appreciated the
informative and concise section 3 "overview". The flow and the explanations are
really superb: if only all published RFC could have this level of quality ;-)

While I appreciate that the document shepherd was the past Jim Schaad, I find
it weird to read a shepherd's review is for the -21 revision while the balloted
revision is -38 as I usually rely on those write-ups to get an idea about the
WG consensus... Anyway I am trusting the responsible AD for this I-D.

Side note: due to lack of time, I have skipped the security and IANA
considerations sections as I trust the responsible AD.

Please find below some non-blocking COMMENT points (but replies would be
appreciated), and some nits.

Last very minor/cosmetic comment about this document as well to the oAuth
terminology: using "refresh tokens" sounds weird to me, I would have preferred
"permanent tokens" or "long-term tokens", but, I am afraid that the train has
left the station for many years ;-) And the same applies for "introspection"
that usually is done internally and does not require a third party as in oAuth
(but this is another train, which has also left the station...).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 3 --
Should references/expansions be added for "HTTP/2, MQTT, BLE and QUIC" ?

-- Section 3.1 --
Suggest to review the order of the definitions, notably popping up
"introspection" as it is used by most of the other terms.

-- Section 4 --
Mostly cosmetic, any reason why figure 1 is so far away from its mention in §1 ?

In "ensure that its content cannot be modified, and if needed, that the content
is confidentiality protected", I wonder why the confidentiality is only
optional ? As far as I understand it, the possession of an access token grants
access to a ressource, so, it should be protected against sniffing. What did I
miss ?

In "If the AS successfully processes the request from the client" may look
ambiguous because processing correctly (per protocol) an invalid credential is
also "successfully processed". Suggest to mention something about "positive
authentication" ;)

-- Section 5 --
As a non-English native speaker, I cannot see the verb in the second
proposition in "For IoT, it cannot be assumed that the client and RS are part
of a common key infrastructure, so the AS provisions credentials or associated
information to allow mutual authentication.". While I obviously understand the
meaning, could it be rephrased ?

-- Section 5.1.1 --
Could the word "unprotected" be better defined in "received on an unprotected
channel" ? E.g., is it only about TLS ? Else, I like the implicit lack of trust.

-- Section 5.1.2 --
I must admit that I have failed to understand the semantic of "audience"... Can
you either explain its meaning or provide a reference ?

-- Section 5.5 --
In "Since it requires the use of a user agent (i.e., browser)" is it "i.e." or
"e.g." ?

-- Section 5.6 --
s/the semantics described below MUST be/the semantics described in this section
MUST be/ ?

In "The default name of this endpoint in an url-path is '/token'" should
"SHOULD" normative language be used ?

-- Section 5.6.4.1 --
In figure 11, would you mind adding the section ID in addition to RFC 6749 ? I
failed to spot them in RFC 6749.

-- Section 5.7.2 --
It is a little unclear to me which profile must be used as 'profile' is
optionnial? Should a default or any profile be used ?

-- Section 5.8.1 --
Suggest to use the BCP14 "SHOULD" in the text "The default name of this
endpoint in an url-path is '/authz-info'"

-- Section 10.2 --
Is RFC 7049 really an informative reference as CBOR appears as the default
encoding ?

== NITS ==

s/application layer protocol/application-layer protocol/ ?

Should multi-words message names (e.g.,  AS Request Creation Hints) be enclosed
by quotes ?

-- Section 2 --
Please introduce "authz-info" before first use.

-- Section 3.1 --
"PoP" is expanded twice in this section ;-)

"CBOR encoding (CWT) " the "CWT" acronym does not match the expansion :-)

-- Section 4 --

Sometimes "Client" is used and sometimes "client" is used...

s/reference to a specific credential/reference to a specific access credential/
?

-- Section 5.1.2 --
Can you introduce to "kid" acronym ? It too me a while to understand that it is
(probably) key-id... :-)

Unsure whether "nonce: h'e0a156bb3f'," is the usual IETF way to introduce an
hexadecimal number.

typo in "5.8.4.  Key Expriation" :-)