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

[Brian Campbell <[e-mail]>]

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


On Mon, Sep 2, 2019 at 3:40 AM Éric Vyncke via Datatracker <[e-mail]>
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._