Thank you, Éric, for the review and ballot position.
On Mon, Sep 2, 2019 at 3:40 AM Éric Vyncke via Datatracker <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
