Subject: [OAUTH-WG] Éric Vyncke's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 02 Sep 2019 02:40:31 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-oauth-resource-indicators-05: 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-oauth-resource-indicators/

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

Thank you for the hard work put into this easy to read document.

Regards,

-éric

== COMMENTS ==

-- Section 1 --
"has uncovered a need, in some circumstances" (and similar sentences in section
1), it is rather vague for a standard track document... Please add some facts
and data, this could be a companion document about requirements/use cases.

-- Section 2 --
It is rather a question of mine, why does the resource need to be a URI (which
usually bears some visible semantics) rather than an opaque string known only
by the resource owner/server ? This is similar to Mirja's comment about privacy.

---

From: ki de <[email-masked]>
Date: Mon, 2 Sep 2019 10:22:53 +0000

On Mon, Sep 2, 2019 at 5:40 AM ?ric Vyncke via Datatracker <[email-masked]> wrote:
?ric Vyncke has entered the following ballot position for
draft-ietf-oauth-resource-indicators-05: No Objection

Please refer to https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&amp;data=02%7C01%7C%7Cda0508bc7b9a4598ae6f08d72f89a104%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637030140461915948&amp;sdata=sK56j9bwVyLlNupgEdxExdaBTTOLnI28%2FYSTJVgLpG4%3D&amp;reserved=0
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-oauth-resource-indicators%2F&amp;data=02%7C01%7C%7Cda0508bc7b9a4598ae6f08d72f89a104%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637030140461925959&amp;sdata=yGz0cyRb7FgYxHtHOMLTScZeIpTSQGb7pu6NOhQF2Ic%3D&amp;reserved=0

Regards,

-?ric

== COMMENTS ==

-- Section 1 --

-- Section 2 --

_______________________________________________
OAuth mailing list
[email-masked]
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=02%7C01%7C%7Cda0508bc7b9a4598ae6f08d72f89a104%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637030140461925959&amp;sdata=QfcbDqqJ9Z6g%2BLq8dNAAizQcLfpLxR543GBaqZwiAsw%3D&amp;reserved=0

---

From: Brian Campbell <[email-masked]>
Date: Tue, 3 Sep 2019 13:28:35 -0600

Thank you, Éric, for the review and ballot position.

> COMMENT:

Thanks, I'm happy to hear that you found it readable.

> and data, this could be a companion document about requirements/use cases.

Sec 1 is intended to be a general (though not vague) introduction with some
explanation about what an authorization server might be able to accomplish
with an understanding of the location/identity of the protected resource
for which the client is requesting an access token. Which effectively boils
down to being able to produce the token appropriate for the indicated
resource (including the type of token, if and how it's encrypted, what
information is contained or referenced, to whom it is audience restricted).
I've no doubt that the writing could stand to be improved (which is always
the case with content I've written) but those are the use cases and I don't
have more specific facts or data.

> by the resource owner/server ? This is similar to Mirja's comment about

The motivation behind the draft is largely to facilitate this explicit
signal to the authorization server (AS) about the location or identity of
the protected resource for which the client is requesting an access token.
For the reasons previously mentioned. Something that's opaque to the AS
would negate the ability of the AS to do most of that stuff (admittedly not
all but most).

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 4 Sep 2019 07:59:54 +0000

Brian,

Thank you for your reply and the explanation about the URI vs. an opaque value (still wondering though about the privacy leaks but perhaps less important in the world of OAuth).

I believe that the document would benefit if you could add some more examples/use cases in section 1. Up to the authors.

Regards

-éric

From: Brian Campbell <[email-masked]>
Date: Tuesday, 3 September 2019 at 21:29
To: Eric Vyncke <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, oauth <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [OAUTH-WG] Éric Vyncke's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)

On Mon, Sep 2, 2019 at 3:40 AM Éric Vyncke via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Éric Vyncke has entered the following ballot position for
draft-ietf-oauth-resource-indicators-05: No Objection
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

== COMMENTS ==

-- Section 1 --

Sec 1 is intended to be a general (though not vague) introduction with some explanation about what an authorization server might be able to accomplish with an understanding of the location/identity of the protected resource for which the client is requesting an access token. Which effectively boils down to being able to produce the token appropriate for the indicated resource (including the type of token, if and how it's encrypted, what information is contained or referenced, to whom it is audience restricted). I've no doubt that the writing could stand to be improved (which is always the case with content I've written) but those are the use cases and I don't have more specific facts or data.

-- Section 2 --

The motivation behind the draft is largely to facilitate this explicit signal to the authorization server (AS) about the location or identity of the protected resource for which the client is requesting an access token. For the reasons previously mentioned. Something that's opaque to the AS would negate the ability of the AS to do most of that stuff (admittedly not all but most).

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.