On Fri, 15 Nov 2019 at 04:41, Torsten Lodderstedt <[email protected]> wrote:
> > On 14. Nov 2019, at 08:31, Ryan Kelly <[email protected]> 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
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
