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

[Justin Richer]

+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 
mailto:gffle...@aol.com>> 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": ""
}
}

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 
mailto:jric...@mit.edu>> 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 
mailto:bcampb...@pingidentity.com>> 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 
mailto:jus...@bspk.io>> 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 
mailto:gffle...@aol.com>> 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 

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

[Torsten Lodderstedt]

> On 8. Oct 2019, at 16:49, George Fletcher  
> 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": ""
> }
> }
> 
> 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
> 
> 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  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  
>>> 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  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  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.??
> 

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

[George Fletcher]

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": "" } }|


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 > 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
mailto:bcampb...@pingidentity.com>>
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 mailto:jus...@bspk.io>> 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
mailto:gffle...@aol.com>> 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 

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

[Brian Campbell]

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  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 
> 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  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  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: *internet-dra...@ietf.org
>> *Subject: **New Version Notification for
>> draft-lodderstedt-oauth-rar-02.txt*
>> *Date: *21. September 2019 at 16:10:48 CEST
>> *To: *"Justin Richer" , "Torsten Lodderstedt" <
>> tors...@lodderstedt.net>, "Brian Campbell" 
>>
>>
>> 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: 

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

[Justin Richer]

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 
mailto:bcampb...@pingidentity.com>> 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 
mailto:jus...@bspk.io>> 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 
mailto:gffle...@aol.com>> 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: internet-dra...@ietf.org
Subject: New Version Notification for draft-lodderstedt-oauth-rar-02.txt
Date: 21. September 2019 at 16:10:48 CEST
To: "Justin Richer" mailto:i...@justin.richer.org>>, 
"Torsten Lodderstedt" 
mailto:tors...@lodderstedt.net>>, "Brian Campbell" 
mailto:bcampb...@pingidentity.com>>


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 

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

[Torsten Lodderstedt]

Hi Janak, 

thanks for your feedback. 

> On 22. Sep 2019, at 09:45, Janak Amarasena  wrote:
> 
> Hi,
> 
> Since the "authorization_details" parameter is newly introduced I feel it 
> would be better to show how this is used with the existing authorization 
> request at the beginning of the specification. Maybe a small sample of the 
> complete authorization request in the "introduction" section.

Sounds reasonable, I put it on the list for the next revision. 

> 
> Also, in the "Security Considerations" section it says 
> Authorization details are sent through the user agent in case of an
> OAuth authorization request, which makes them vulnerable to
> modifications by the user.
> 
> Do we really need to worry that the "authorization_details" could be 
> manipulated by the user(Resource Owner) as the client is trying to access the 
> users' resources which the user is giving consent to? Also, the resulting 
> token will contain the given permissions as well. 

I understand. I think the more general case of modifying the Authorization 
Request content, e.g. PKCE challenge, and swapping such parameters between 
different devices is the important attack vector. I will improve the text.

best regards,
Torsten. 

> 
> Best Regards,
> Janak Amarasena
> 
> On Sat, Sep 21, 2019 at 11:21 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: internet-dra...@ietf.org
>> Subject: New Version Notification for draft-lodderstedt-oauth-rar-02.txt
>> Date: 21. September 2019 at 16:10:48 CEST
>> To: "Justin Richer" , "Torsten Lodderstedt" 
>> , "Brian Campbell" 
>> 
>> 
>> 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 list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth