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 for working on this! It's an interesting and timely read for me 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.
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. 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?
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"? What if the "resource" parameter refers to a value that was
present in "locations" but not in "resource" during the initial
authorization request?
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?
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.
* 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?
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
>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
