Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-rar-03.txt

[Ryan Kelly <[e-mail]>]

On Fri, 15 Nov 2019 at 04:41, Torsten Lodderstedt <[e-mail]>
wrote:

> > On 14. Nov 2019, at 08:31, Ryan Kelly <[e-mail]> wrote:
> >
> > In Paragraph 3, how should the AS deal with authorization details
> objects that do not have a "locations" element? Should they be included
> regardless of "resource”?
>
> That’s a very good question. I see to options:
> - those elements are assigned to any access token
> - those elements are assigned to an access token in case there was no
> “resource” parameter included in the token request.
>
> I’m leaning towards the latter approach.
>
> > What if the "resource" parameter refers to a value that was present in
> "locations" but not in "resource" during the initial authorization request?
>
> See above - since locations take precedence, those locations shall match.
>

Gotcha, thanks. I think this is the part I wasn't clear on regarding the
meaning of "take precedence" at the authorization endpoint, and I wonder if
it can be made more explicit in the earlier section.


> > The "matches as prefix of one of the URLs" part of Paragraph 3 seems a
> bit unclear as well, given that there is no requirement that the
> "locations" elements be well-formed URLs. Is this is simple string prefix
> match, or some sort of path matching based on the components of the URL?
>
> simple string match
>

Does the AS need to take any particular care about resource names that
might accidentally be prefixes of each other, such as "
https://example.com/payments" and "https://example.com/payme"?  That seems
really contrived, but perhaps I'm just not creative enough to think of a
more realistic example.


> > * Section 3: Using "authorization_details"
> >
> > Intuitively, I would expect to be able to use "authorization_details" in
> a token request using grant_type=refresh_token, in the same way that I can
> specify "scope". Section 3 doesn't seem to take a definitive stance on this
> - IIUC Section 3.1 doesn't apply because this is not an authorization
> request, and Section 3.3 seems to discourage it in favour of using the
> "resource" parameter. Do you intend for this parameter to be allowed in
> conjunction with a refresh token?
>
> What would be the use case for passing an authorization details parameter
> to the token request with a refresh token? The client shouldn’t be able to
> change the authorization details of the underlying grant, so using the
> “resource” parameter to select another subset of the granted authorization
> details should be sufficient.
>

I was thinking of situations where there might be "high risk" and "low
risk" actions authorized for a single resource server, and the client may
want to make an access token that is scoped down to just the low-risk ones,
to minimize the impact of a potential compromise of that token. But perhaps
that's better dealt with by the work on sender-constrained tokens to reduce
the risk of the token being compromised in the first place.

  Cheers,

    Ryan