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

[George Fletcher <[e-mail]>]

In general, it's difficult to determine how to extend for new types or 
if they should be wrapped up in "data" somehow.

|{ "type":"https://example.com/my_field", "actions":[ "read" ], 
"my_field": { "id": "<id_value>" } }|

I'm assuming the above is perfectly legit and the intended way for the 
spec to be extended? If not, what is the expected extension mechanism?

Thanks,
George

On 10/2/19 11:45 AM, Brian Campbell wrote:
> I guess we differ in our opinion of how remiss that would be. But 
> given what you've got in there now, the more narrow point I was trying 
> to make was to say that I don't think "data" is defined or explained 
> well enough to be helpful.
>
> On Tue, Oct 1, 2019 at 4:33 PM Justin Richer <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     I think that we need to define :some: common set to data elements
>     in this spec, in order to help people who are using this and
>     trying to apply it to their APIs do so in vaguely consistent ways.
>     The details of which parts we standardize on are still, I think,
>     up for grabs. I???d be happy to have a better name than ???data??? for
>     this aspect, but I think there???s value in defining this kind of
>     thing. Like in the financial space, it???s the difference between
>     ???transactions??? and ???accounts???. Or in the medical space, there???s
>     ???demographics??? and ???appointments??? and ???testResults???. This is a
>     very, very, very common way to slice up OAuth-protected resources,
>     and we???d be remiss to leave it undefined and just have every API
>     developer need to come up with their own version of the same thing.
>
>     ??? Justin
>
>>     On Oct 1, 2019, at 2:40 PM, Brian Campbell
>>     <[e-mail] <mailto:[e-mail]>>
>>     wrote:
>>
>>     I'm not entirely sold on the draft attempting to define this set
>>     of common data elements in the first place. But that said, I
>>     think (similar to George?) I'm struggling with "data" more than
>>     the others. The definition in the -02 draft is an "array of
>>     strings representing the kinds of data being requested from the
>>     resource" and I'm honestly having a hard time understanding what
>>     that actually means or how it would be used in practice. And I'm
>>     not sure roughly equating it to ???what kind of thing I want???
>>     helped me understand any better.
>>
>>     On Tue, Sep 24, 2019 at 5:34 PM Justin Richer <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>         The idea behind the ???locations???, ???actions???, ???data???, and
>>         ???identifier??? data element types mirrors what I???ve seen
>>         ???scope??? used for in the wild. They roughly equate to ???where
>>         something is???, ???what I want to do with it???, ???what kind of
>>         thing I want???, and ???the exact thing I want???, respectively.
>>         I???m completely open for better names, and have even been
>>         thinking ???datatype??? might be better than just ???data??? for the
>>         third one.
>>
>>         As for encoding, I think that form encoding makes sense
>>         because it???s the simplest possible encoding that will work. I
>>         personally don???t see a need to armor this part of the request
>>         with base64, as it is in JOSE, and doing so would make it one
>>         more step removed from easy developer understanding.
>>
>>         -- Justin Richer
>>
>>         Bespoke Engineering
>>         [phone]
>>         https://bspk.io/
>>
>>
>>
>>>         On Sep 24, 2019, at 1:45 PM, George Fletcher
>>>         <[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>         Just two questions...
>>>
>>>         1. What is the rationale that 'data' is really an array of
>>>         arbitrary top-level claims? I find looking at the spec and
>>>         not finding a 'data' section a little confusing.
>>>
>>>         2. What is the rationale for sending the JSON object as a
>>>         urlencoded JSON string rather than a base64url encoded JSON
>>>         string? The later would likely be smaller and easier to read:)
>>>
>>>         Thanks,
>>>         George
>>>
>>>         On 9/21/19 1:51 PM, Torsten Lodderstedt wrote:
>>>>         Hi all,??
>>>>
>>>>         I just published a draft about ???OAuth 2.0 Rich
>>>>         Authorization Requests??? (formerly known as ???structured
>>>>         scopes???).??
>>>>
>>>>         https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02
>>>>
>>>>         It specifies a new
>>>>         parameter?????authorization_details"??that is used to carry
>>>>         fine grained authorization data in the OAuth authorization
>>>>         request. This mechanisms was designed based on experiences
>>>>         gathered in the field of open banking, e.g. PSD2, and is
>>>>         intended to make the implementation of rich and transaction
>>>>         oriented authorization requests much easier than with
>>>>         current OAuth 2.0.
>>>>
>>>>         I???m happy that Justin Richer and Brian Campbell joined me
>>>>         as authors of this draft. We would would like to thank
>>>>         Daniel Fett, Sebastian Ebling, Dave Tonge, Mike Jones, Nat
>>>>         Sakimura, and Rob Otto for their valuable feedback during
>>>>         the preparation of this draft.
>>>>
>>>>         We look forward to getting your feedback.??
>>>>
>>>>         kind regards,
>>>>         Torsten.??
>>>>
>>>>>         Begin forwarded message:
>>>>>
>>>>>         *From: *[e-mail]
>>>>>         <mailto:[e-mail]>
>>>>>         *Subject: **New Version Notification for
>>>>>         draft-lodderstedt-oauth-rar-02.txt*
>>>>>         *Date: *21. September 2019 at 16:10:48 CEST
>>>>>         *To: *"Justin Richer" <[e-mail]
>>>>>         <mailto:[e-mail]>>, "Torsten Lodderstedt"
>>>>>         <[e-mail]
>>>>>         <mailto:[e-mail]>>, "Brian Campbell"
>>>>>         <[e-mail]
>>>>>         <mailto:[e-mail]>>
>>>>>
>>>>>
>>>>>         A new version of I-D, draft-lodderstedt-oauth-rar-02.txt
>>>>>         has been successfully submitted by Torsten Lodderstedt and
>>>>>         posted to the
>>>>>         IETF repository.
>>>>>
>>>>>         Name:draft-lodderstedt-oauth-rar
>>>>>         Revision:02
>>>>>         Title:OAuth 2.0 Rich Authorization Requests
>>>>>         Document date:2019-09-20
>>>>>         Group:Individual Submission
>>>>>         Pages:16
>>>>>         URL:
>>>>>         ??????????????????????https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-02.txt
>>>>>         Status:
>>>>>         ????????????????https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
>>>>>         Htmlized:
>>>>>         ????????????https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02
>>>>>         Htmlized:
>>>>>         ????????????https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar
>>>>>         Diff:
>>>>>         ????????????????????https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-rar-02
>>>>>
>>>>>         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 <http://tools.ietf.org/>.
>>>>>
>>>>>         The IETF Secretariat
>>>>>
>>>>
>>>>
>>>>         _______________________________________________
>>>>         OAuth mailing list
>>>>         [e-mail]  <mailto:[e-mail]>
>>>>         https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>         _______________________________________________
>>         OAuth mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>     /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./
>
>
> /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./