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 <bcampb...@pingidentity.com> Date: Tuesday, 3 September 2019 at 21:29 To: Eric Vyncke <evyn...@cisco.com> Cc: The IESG <i...@ietf.org>, "draft-ietf-oauth-resource-indicat...@ietf.org" <draft-ietf-oauth-resource-indicat...@ietf.org>, oauth <oauth@ietf.org>, "oauth-cha...@ietf.org" <oauth-cha...@ietf.org> Subject: Re: [OAUTH-WG] Éric Vyncke's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT) Thank you, Éric, for the review and ballot position. On Mon, Sep 2, 2019 at 3:40 AM Éric Vyncke via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> wrote: Éric Vyncke has entered the following ballot position for draft-ietf-oauth-resource-indicators-05: No Objection ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the hard work put into this easy to read document. Thanks, I'm happy to hear that you found it readable. == 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. 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 -- 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. 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.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
