Hi Ryan, > On 14. Nov 2019, at 08:31, Ryan Kelly <[email protected]> wrote: > > > > Hi, > > (I've been lurking on this list for a while but I don't think I've posted > here before, so...hi! I'm Ryan and I work on Firefox Accounts and related > systems at Mozilla).
thanks a lot for posting your feedback! > > Thanks for working on this! It's an interesting and timely read for me Good to hear we are just in time :-) > as we're starting to bump up against some limitations of the `scope` > parameter. I have some initial feedback below, and will hopefully be able to > send through more as I dig in in more detail. please do > > Cheers, > > Ryan > > --- > > * Section 2.3: Relationship to "resource" parameter > > The potential interactions between "locations" and "resource" seem very > complex and I'm not at all sure I understood them. > > Paragraph 2 says that "locations" should take precedence over "resource" when > both appear in the authorization request, but doesn't explain what this means > in concrete terms. I see. This is related to the section 2.1. of draft-ietf-oauth-resource-indicators, where the use of the “resource” parameter in the authorization request is described as "When the "resource" parameter is used in an authorization request to the authorization endpoint, it indicates the identity of the protected resource(s) to which access is being requested.” The “locations" elements of the authorisation details objects do the same but on a more detailed level. That’s why this information shall take precedence. Given there could be authorisation details objects that do not contain a locations element, it nevertheless could be useful to use “resource” in parallel. However, one could also argue that client using locations should do you consequently and not use the “resource” parameter in the authorization request. > Can a client make a subsequent token request that passes a value from > "locations" in the "resource" parameter, even though it wasn't specified in > the "resource" parameter of the authorization request? yes. At the token endpoint, the “resource” parameter is the only way to describe what resource server the client want to use the token at. draft-lodderstedt-oauth-rar does not use an alternative parameter at the token endpoint, it in some ways utilises the existing “resource” parameter. Or put the other way around, it makes the semantics of the “resource” parameter more explicit. Where draft-ietf-oauth-resource-indicators states "To the extent possible, when issuing access tokens, the authorization server should downscope the scope value associated with an access token to the value the respective resource is able to process and needs to know.” draft-lodderstedt-oauth-rar makes that more explicit/transparent by requiring "The AS will select all authorization details object where the "resource" string matches as prefix of one of the URLs provided in the respective "locations" element." > > 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. > > 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 > > As a purely stylistic comment, I also found the example in this section a bit > artificial - I struggled to think of *why* a client might request an > authorization code with one set of authorization details, but then use the > "resource" parameter to immediately reduce them when exchanging the code for > a token. I wonder if using a refresh_token grant as part of the example could > help make it clearer, similar to what's done in oauth-resource-indicators-08 > Section 2.2. I think asking for an access token for a single resource server is just consequent, since it ensures all access tokens are tightly audience restricted. But you are making a good point, a further example utilising the refresh token to obtain another access token for the other resource server will certainly make things clearer. > > > * 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. best regards, Torsten. > > > > On Tue, 5 Nov 2019 at 03:48, Torsten Lodderstedt <[email protected]> > wrote: > Hi all, > > a new (significantly enhanced) revision of draft-lodderstedt-oauth-rar was > just published. Here is the list of changes: > > • Reworked examples to illustrate privacy preserving use of > authorization_details > • Added text on audience restriction > • Added description of relationship between scope and > authorization_details > • Added text on token request & response and authorization_details > • Added text on how authorization details are conveyed to RSs by JWTs > or token endpoint response > • Added description of relationship between claims and > authorization_details > • Added more example from different sectors > • Clarified string comparison to be byte-exact without collation > > Thanks a lot for all contributions and the review feedback so far. I will > present this draft in Singapore and would appreciate if the WG would consider > this draft for adoption. > > best regards, > Torsten. > >> Begin forwarded message: >> >> From: [email protected] >> Subject: New Version Notification for draft-lodderstedt-oauth-rar-03.txt >> Date: 4. November 2019 at 17:43:01 CET >> To: "Justin Richer" <[email protected]>, "Torsten Lodderstedt" >> <[email protected]>, "Brian Campbell" <[email protected]> >> >> >> A new version of I-D, draft-lodderstedt-oauth-rar-03.txt >> has been successfully submitted by Torsten Lodderstedt and posted to the >> IETF repository. >> >> Name: draft-lodderstedt-oauth-rar >> Revision: 03 >> Title: OAuth 2.0 Rich Authorization Requests >> Document date: 2019-11-03 >> Group: Individual Submission >> Pages: 30 >> URL: >> https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-03.txt >> Status: https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/ >> Htmlized: https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-03 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-rar-03 >> >> Abstract: >> This document specifies a new parameter "authorization_details" that >> is used to carry fine grained authorization data in the OAuth >> authorization request. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
