In the ten years since OAuth started, we’ve seen a huge shift away from form
encoding to JSON encoding for sending data to a server. And yet, OAuth is stuck
with form encoding. So I thought, why can’t we change that?
I put together a quick proposal for how this would work.
https://www.ietf.org/
> On 9 Jul 2020, at 18:34, Torsten Lodderstedt wrote:
>
>> On 9. Jul 2020, at 19:28, Neil Madden wrote:
>>
>> On 9 Jul 2020, at 18:10, Torsten Lodderstedt wrote:
>>>
>>>
>>>
>>> What in particular should the use consent with in this step?
>>
>> “Foo
> On 9. Jul 2020, at 19:28, Neil Madden wrote:
>
> On 9 Jul 2020, at 18:10, Torsten Lodderstedt wrote:
>>
>>
>>
>> What in particular should the use consent with in this step?
>
> “FooPay would like to:
> - initiate payments from your account
On 9 Jul 2020, at 18:10, Torsten Lodderstedt wrote:
>
>
>
> What in particular should the use consent with in this step?
“FooPay would like to:
- initiate payments from your account (you will be asked to approve
each one)”
On 9 Jul 2020, at 17:06, Dave Tonge wrote:
>
> Hi Neil
>
> RAR doesn't have to be transactional and people are already using standard
> OAuth for transactions without RAR.
> But I take your point that RAR is promoting a more transactional use of
> OAuth.
> However I still don't agree that the
What in particular should the use consent with in this step?
>>>
>>> “FooPay would like to:
>>> - initiate payments from your account (you will be asked to approve
>>> each one)”
>>>
>>> The point is that a client that I don’t have any kind of relation
On 09/07/2020 19:06, Dave Tonge wrote:
>
> If a particular implementation wants to allow a two stage transaction,
> they can simply pass some reference to the first auth in the
> subsequent RAR auth flows, e.g.
>
> First flow, a user grants access with the simple scope of
> "make_payments", the ac
Hi Neil
RAR doesn't have to be transactional and people are already using standard
OAuth for transactions without RAR.
But I take your point that RAR is promoting a more transactional use of
OAuth.
However I still don't agree that there is a fundamental difference.
Revocation of access is irreleva
> On 9 Jul 2020, at 09:53, Vladimir Dzhuvinov wrote:
> On 09/07/2020 11:07, Neil Madden wrote:
>>
>>>
>>> An AS is always free to implement the 2 step solution that you proposed and
>>> indeed it could be easier to implement with RAR in the manner you
>>> described, but I don't think it shou
On 09/07/2020 11:07, Neil Madden wrote:
>
>>
>> An AS is always free to implement the 2 step solution that you
>> proposed and indeed it could be easier to implement with RAR in the
>> manner you described, but I don't think it should be the prescribed
>> approach.
>
> How can an AS implement this
> On 9 Jul 2020, at 08:28, Dave Tonge wrote:
>
>
> Hi Neil
>
> From a conceptual point of view I'm not really sure what RAR changes from
> vanilla OAuth?
> For example what is the difference between a client redirecting a user to an
> AS in order to:
> - grant access to sensitive health d
> On 9 Jul 2020, at 07:33, Torsten Lodderstedt wrote:
>
>
>
>>> On 8. Jul 2020, at 23:52, Neil Madden wrote:
>>>
>>>
On 8 Jul 2020, at 20:56, Torsten Lodderstedt
wrote:
>>>
Am 08.07.2020 um 20:46 schrieb Neil Madden :
On 8 Jul 2020, at 19:03, Torsten Lodderst
Hi Neil
>From a conceptual point of view I'm not really sure what RAR changes from
vanilla OAuth?
For example what is the difference between a client redirecting a user to
an AS in order to:
- grant access to sensitive health data
- initiate a specific payment
- grant full read/write access to
13 matches
Mail list logo
