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

From: Brian Campbell <[email-masked]>
Date: Tue, 1 Oct 2019 15:40:19 -0600

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 <[email-masked]> 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
> +1 (617) 564-3801
> https://bspk.io/
>
>
>
> On Sep 24, 2019, at 1:45 PM, George Fletcher <[email-masked]> 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: [email-masked]
> *Subject: **New Version Notification for
> draft-lodderstedt-oauth-rar-02.txt*
> *Date: *21. September 2019 at 16:10:48 CEST
> *To: *"Justin Richer" <[email-masked]>, "Torsten Lodderstedt" <
> [email-masked]>, "Brian Campbell" <[email-masked]>
>
>
> 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.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> 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._

---

From: Justin Richer <[email-masked]>
Date: Tue, 1 Oct 2019 22:33:29 +0000

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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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
+1 (617) 564-3801
https://bspk.io/

On Sep 24, 2019, at 1:45 PM, George Fletcher <[email-masked]<mailto:[email-masked]>> 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

I just published a draft about ???OAuth 2.0 Rich Authorization Requests??? (formerly known as ???structured scopes???).??

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.

kind regards,
Torsten.??

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-lodderstedt-oauth-rar-02.txt
Date: 21. September 2019 at 16:10:48 CEST
To: "Justin Richer" <[email-masked]<mailto:[email-masked]>>, "Torsten Lodderstedt" <[email-masked]<mailto:[email-masked]>>, "Brian Campbell" <[email-masked]<mailto:[email-masked]>>

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:

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
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.

---

From: Brian Campbell <[email-masked]>
Date: Wed, 2 Oct 2019 09:45:14 -0600

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 <[email-masked]> 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 <[email-masked]>
> wrote:
>
>> I just published a draft about ???OAuth 2.0 Rich Authorization
>> Requests??? (formerly known as ???structured scopes???).??
>>
> *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.*
>
>
>

---

From: George Fletcher <[email-masked]>
Date: Tue, 8 Oct 2019 10:49:31 -0400

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 <[email-masked] 
> <mailto:[email-masked]>> 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
>>     <[email-masked] <mailto:[email-masked]>>
>>     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.
>>
>>         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
>>         +1 (617) 564-3801
>>         https://bspk.io/
>>
>>
>>
>>>         On Sep 24, 2019, at 1:45 PM, George Fletcher
>>>         <[email-masked] <mailto:[email-masked]>> 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
>>>
>>>>         I just published a draft about ???OAuth 2.0 Rich
>>>>         Authorization Requests??? (formerly known as ???structured
>>>>         scopes???).??
>>>>
>>>>         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.
>>>>
>>>>>         <mailto:[email-masked]>
>>>>>         *To: *"Justin Richer" <[email-masked]
>>>>>         <mailto:[email-masked]>>, "Torsten Lodderstedt"
>>>>>         <[email-masked]
>>>>>         <mailto:[email-masked]>>, "Brian Campbell"
>>>>>         <[email-masked]
>>>>>         <mailto:[email-masked]>>
>>>>>
>>>>>
>>>>>         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:
>>>>>         until the htmlized version and diff are available at
>>>>>         tools.ietf.org <http://tools.ietf.org/>.
>>>>>
>>>>>         The IETF Secretariat
>>>>>
>>>>
>>>>
>>>>         [email-masked]  <mailto:[email-masked]>
>>         [email-masked] <mailto:[email-masked]>
>>     /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 
> 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./

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 8 Oct 2019 17:36:29 +0200

> On 8. Oct 2019, at 16:49, George Fletcher <gffletch=[email-masked]> wrote:
> 
> 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?

That’s the intended way to go. Do you have an idea how we could convey that even better in the text?

> If not, what is the expected extension mechanism?
> 
> Thanks,
> George
> 
>> 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 Oct 1, 2019, at 2:40 PM, Brian Campbell <[email-masked]> wrote:
>>> 
>>>>>> From: [email-masked]
>>>>>> To: "Justin Richer" <[email-masked]>, "Torsten Lodderstedt" <[email-masked]>, "Brian Campbell" <[email-masked]>
>>>>>> 
>>>>>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 10 Oct 2019 01:14:42 +0000

+1, that’s the idea — schema by fiat at the very least. This structure should be a flexible JSON object that can take whatever shape its attendant API would need it to have. The goal of the “common data elements” is to provide just enough structure to be generally useful, and it’s based on what dimensions I’ve seen “scope” used for in the wild most often. If you’ve got your own fields and dimensions, then those definitely should be their own space and not crammed into the existing ones. But if you’ve got something that feels like an “action”? Use that space.

— Justin

On Oct 8, 2019, at 10:49 AM, George Fletcher <[email-masked]<mailto:[email-masked]>> wrote:

{
    "type":"https://example.com/my_field"<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 Tue, Oct 1, 2019 at 4:33 PM Justin Richer <[email-masked]<mailto:[email-masked]>> 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

-- Justin Richer

Bespoke Engineering
+1 (617) 564-3801
https://bspk.io/

Just two questions...

Thanks,
George

kind regards,
Torsten.??

Begin forwarded message:

Abstract:

The IETF Secretariat