Re: [OAUTH-WG] Rotating client secret

[Amarendra Godbole]

Ah! That isn’t the issue as much as the fact that Admin B does not want to 
share the client_secret with Admin A in the first place!

As Dick Hardt suggested earlier, we are already considering moving it up a 
layer since this is largely a trust-between-humans-issue, though its still a 
bummer that OAuth2 doesn’t support rotating client_secret.

Thanks everyone who responded, I have enough food for thought!

-Amarendra

--
sent via recycled electrons, from my portable command center.



> On Jul 13, 2020, at 3:50 PM, Warren Parad  wrote:
> 
> Why is #3 a problem, and why do the admin A incorrectly use App A to store 
> the service credentials of App B in their repository? Admin A should be using 
> their source control/database to store the tenant B client secret.
> 
> Warren Parad
> Secure your user data and complete your authorization architecture. Implement 
> Authress .
>  
> 
> On Mon, Jul 13, 2020 at 11:34 PM Amarendra Godbole  > wrote:
> Let me see if I can provide more details on the usecase:
> 1. A tenant is subscribed to SaaS application A and SaaS application B, and 
> both applications are separately managed by different teams in the same 
> organization. No assumption can be made about the trust between those teams.
> 2. Application A backend is supposed to access Application B. App B also has 
> the authorization server. Both applications expose administration UI for its 
> tenants.
> 3. App B admin generates client_id and client_secret, and hands them over to 
> App A admin.
> 4. App A admin enters the client_id and clilent_secret in the UI, so the 
> backend App A can now communicate with/access App B.
> 
> #3 exposes client credentials of App B to admins of app A — this is our 
> problem. As stated in #1, we cannot make any assumptions about the level of 
> trust between the two groups.
> 
> If OAuth2 provided a client credential rotation, this exposure of credentials 
> can be limited to a small time window. The original client_secret can be a 
> one-time-use-bootstrap, that App A backend exchanges for another secret from 
> the authorization server. Generalizing it, the OAuth2 spec can provide for 
> servers to trigger a client_secret rotation.
> 
> To your analogy, the front-end app can “leak” the credentials during 
> provisioning (it can be a simple copy/paste that the user has to do), thus 
> creating a security issue. But if the credentials are one-time-bootstrap, 
> then first time the front-end app connects to Google drive, drive changes the 
> client_secret for a different one, which then would be used by front-end app 
> in the future. Drive also has the ability to periodically rotate the 
> client_secret in a similar manner. This assumes front-end app cannot access 
> the client_secret once it is provisioned.
> 
> Is this better? Thanks!
> 
> -Amarendra
> 
> --
> sent via recycled electrons, from my portable command center.
> 
> 
> 
>> On Jul 13, 2020, at 1:48 PM, Warren Parad > > wrote:
>> 
>> I'm not sure if it is just me, but I'm not sure I'm totally following.
>> 
>> I can see a concrete analogy being that, Tenant application B could be 
>> Google Drive, and Tenant application A being any front end app that wants to 
>> offer a service that saves files in a user's Google Drive. If application A 
>> wants to interact with application B offline then tenant A needs a service 
>> client/secret along with an authorization grant initiated through 
>> application A (currently via UI in OAuth2).
>> 
>> Whether application A cycles the client secret or not seems like a different 
>> problem. But I think I'm missing something. Given the example I provided, 
>> would you be able to provide more insight into the problem you are seeing?
>> 
>> Warren Parad
>> Secure your user data and complete your authorization architecture. 
>> Implement Authress .
>>  
>> 
>> On Mon, Jul 13, 2020 at 10:36 PM Amarendra Godbole 
>> mailto:40broadcom@dmarc.ietf.org>> 
>> wrote:
>> Hi All,
>> 
>> First post to the list, and hopefully I am articulate enough to describe the 
>> problem I am facing — did OAuth ever consider an ability to dynamically 
>> rotate client secret (part of the “client credentials” authorization grant)? 
>> I stumbled across rfc7591 (OAuth 2.0 Dynamic Client Registration Protocol), 
>> but the OAuth 2.0 implementation I am looking at [1], does not support it. I 
>> also found some previous reference to client secret rotation [2], but it 
>> does not discuss my use case.
>> 
>> We operate a SaaS application A, which is supposed to talk with another SaaS 
>> application B. Our customers subscribe to both, our application A as well as 
>> application B. However, the teams adminstering A and B are separate teams 
>> within the same organization, though we cannot assume the level of trust 
>> between them. Let’s call them Tenant Admin A and Tenan

Re: [OAUTH-WG] Rotating client secret

[Warren Parad]

Why is #3 a problem, and why do the admin A incorrectly use App A to store
the service credentials of App B in their repository? Admin A should be
using their source control/database to store the tenant B client secret.


*Warren Parad*
Secure your user data and complete your authorization architecture.
Implement Authress .



On Mon, Jul 13, 2020 at 11:34 PM Amarendra Godbole  wrote:

> Let me see if I can provide more details on the usecase:
> 1. A tenant is subscribed to SaaS application A and SaaS application B,
> and both applications are separately managed by different teams in the same
> organization. No assumption can be made about the trust between those teams.
> 2. Application A backend is supposed to access Application B. App B also
> has the authorization server. Both applications expose administration UI
> for its tenants.
> 3. App B admin generates client_id and client_secret, and hands them over
> to App A admin.
> 4. App A admin enters the client_id and clilent_secret in the UI, so the
> backend App A can now communicate with/access App B.
>
> #3 exposes client credentials of App B to admins of app A — *this is our
> problem*. As stated in #1, we cannot make any assumptions about the level
> of trust between the two groups.
>
> If OAuth2 provided a client credential rotation, this exposure of
> credentials can be limited to a small time window. The original
> client_secret can be a one-time-use-bootstrap, that App A backend exchanges
> for another secret from the authorization server. Generalizing it, the
> OAuth2 spec can provide for servers to trigger a client_secret rotation.
>
> To your analogy, the front-end app can “leak” the credentials during
> provisioning (it can be a simple copy/paste that the user has to do), thus
> creating a security issue. But if the credentials are one-time-bootstrap,
> then first time the front-end app connects to Google drive, drive changes
> the client_secret for a different one, which then would be used by
> front-end app in the future. Drive also has the ability to periodically
> rotate the client_secret in a similar manner. This assumes front-end app
> cannot access the client_secret once it is provisioned.
>
> Is this better? Thanks!
>
> -Amarendra
>
> --
> sent via recycled electrons, from my portable command center.
>
>
>
> On Jul 13, 2020, at 1:48 PM, Warren Parad  wrote:
>
> I'm not sure if it is just me, but I'm not sure I'm totally following.
>
> I can see a concrete analogy being that, Tenant application B could be
> Google Drive, and Tenant application A being any front end app that wants
> to offer a service that saves files in a user's Google Drive. If
> application A wants to interact with application B offline then tenant A
> needs a service client/secret along with an authorization grant initiated
> through application A (currently via UI in OAuth2).
>
> Whether application A cycles the client secret or not seems like a
> different problem. But I think I'm missing something. Given the example I
> provided, would you be able to provide more insight into the problem you
> are seeing?
>
>
> *Warren Parad*
> Secure your user data and complete your authorization architecture.
> Implement Authress .
> 
>
>
> On Mon, Jul 13, 2020 at 10:36 PM Amarendra Godbole  40broadcom@dmarc.ietf.org> wrote:
>
>> Hi All,
>>
>> First post to the list, and hopefully I am articulate enough to describe
>> the problem I am facing — did OAuth ever consider an ability to dynamically
>> rotate client secret (part of the “client credentials” authorization
>> grant)? I stumbled across rfc7591 (OAuth 2.0 Dynamic Client Registration
>> Protocol), but the OAuth 2.0 implementation I am looking at [1], does not
>> support it. I also found some previous reference to client secret rotation
>> [2], but it does not discuss my use case.
>>
>> We operate a SaaS application A, which is supposed to talk with another
>> SaaS application B. Our customers subscribe to both, our application A as
>> well as application B. However, the teams adminstering A and B are separate
>> teams within the same organization, though we cannot assume the level of
>> trust between them. Let’s call them Tenant Admin A and Tenant Admin B. In
>> our usecase, application A is the client for application B, and application
>> B provides OAuth 2.0 authorization workflows. Now, Tenant Admin A has to
>> provision the "client credentials” authorization grant — in order to do
>> that, Tenant Admin B generates the client_id and client_secret, and sends
>> them to Tenant Admin B. There is the problem — as I earlier stated, we
>> cannot assume the level of trust between Tenant Admin A and Tenant Admin B,
>> and exchanging client_id and client_secret now means the circle of trust
>> for application B includes individuals who may or may not be trusted.
>>
>> One thought that occured to me was a provision in OAuth 2.0’s client
>> 

Re: [OAUTH-WG] Rotating client secret

[Dick Hardt]

I don't know of any discussion for client secret rotation.

Another way to solve your problem could be to raise it up a layer. Admin B
generates a one time use URL that is sent to Admin A. Admin A visits the
URI and obtains the client_id and client_secret.



On Mon, Jul 13, 2020 at 2:35 PM Amarendra Godbole  wrote:

> Let me see if I can provide more details on the usecase:
> 1. A tenant is subscribed to SaaS application A and SaaS application B,
> and both applications are separately managed by different teams in the same
> organization. No assumption can be made about the trust between those teams.
> 2. Application A backend is supposed to access Application B. App B also
> has the authorization server. Both applications expose administration UI
> for its tenants.
> 3. App B admin generates client_id and client_secret, and hands them over
> to App A admin.
> 4. App A admin enters the client_id and clilent_secret in the UI, so the
> backend App A can now communicate with/access App B.
>
> #3 exposes client credentials of App B to admins of app A — *this is our
> problem*. As stated in #1, we cannot make any assumptions about the level
> of trust between the two groups.
>
> If OAuth2 provided a client credential rotation, this exposure of
> credentials can be limited to a small time window. The original
> client_secret can be a one-time-use-bootstrap, that App A backend exchanges
> for another secret from the authorization server. Generalizing it, the
> OAuth2 spec can provide for servers to trigger a client_secret rotation.
>
> To your analogy, the front-end app can “leak” the credentials during
> provisioning (it can be a simple copy/paste that the user has to do), thus
> creating a security issue. But if the credentials are one-time-bootstrap,
> then first time the front-end app connects to Google drive, drive changes
> the client_secret for a different one, which then would be used by
> front-end app in the future. Drive also has the ability to periodically
> rotate the client_secret in a similar manner. This assumes front-end app
> cannot access the client_secret once it is provisioned.
>
> Is this better? Thanks!
>
> -Amarendra
>
> --
> sent via recycled electrons, from my portable command center.
>
>
>
> On Jul 13, 2020, at 1:48 PM, Warren Parad  wrote:
>
> I'm not sure if it is just me, but I'm not sure I'm totally following.
>
> I can see a concrete analogy being that, Tenant application B could be
> Google Drive, and Tenant application A being any front end app that wants
> to offer a service that saves files in a user's Google Drive. If
> application A wants to interact with application B offline then tenant A
> needs a service client/secret along with an authorization grant initiated
> through application A (currently via UI in OAuth2).
>
> Whether application A cycles the client secret or not seems like a
> different problem. But I think I'm missing something. Given the example I
> provided, would you be able to provide more insight into the problem you
> are seeing?
>
>
> *Warren Parad*
> Secure your user data and complete your authorization architecture.
> Implement Authress .
> 
>
>
> On Mon, Jul 13, 2020 at 10:36 PM Amarendra Godbole  40broadcom@dmarc.ietf.org> wrote:
>
>> Hi All,
>>
>> First post to the list, and hopefully I am articulate enough to describe
>> the problem I am facing — did OAuth ever consider an ability to dynamically
>> rotate client secret (part of the “client credentials” authorization
>> grant)? I stumbled across rfc7591 (OAuth 2.0 Dynamic Client Registration
>> Protocol), but the OAuth 2.0 implementation I am looking at [1], does not
>> support it. I also found some previous reference to client secret rotation
>> [2], but it does not discuss my use case.
>>
>> We operate a SaaS application A, which is supposed to talk with another
>> SaaS application B. Our customers subscribe to both, our application A as
>> well as application B. However, the teams adminstering A and B are separate
>> teams within the same organization, though we cannot assume the level of
>> trust between them. Let’s call them Tenant Admin A and Tenant Admin B. In
>> our usecase, application A is the client for application B, and application
>> B provides OAuth 2.0 authorization workflows. Now, Tenant Admin A has to
>> provision the "client credentials” authorization grant — in order to do
>> that, Tenant Admin B generates the client_id and client_secret, and sends
>> them to Tenant Admin B. There is the problem — as I earlier stated, we
>> cannot assume the level of trust between Tenant Admin A and Tenant Admin B,
>> and exchanging client_id and client_secret now means the circle of trust
>> for application B includes individuals who may or may not be trusted.
>>
>> One thought that occured to me was a provision in OAuth 2.0’s client
>> credentials grant flow was the ability to “bootstrap” a client application
>> — basically the client_secret is on

Re: [OAUTH-WG] Rotating client secret

[Amarendra Godbole]

Let me see if I can provide more details on the usecase:
1. A tenant is subscribed to SaaS application A and SaaS application B, and 
both applications are separately managed by different teams in the same 
organization. No assumption can be made about the trust between those teams.
2. Application A backend is supposed to access Application B. App B also has 
the authorization server. Both applications expose administration UI for its 
tenants.
3. App B admin generates client_id and client_secret, and hands them over to 
App A admin.
4. App A admin enters the client_id and clilent_secret in the UI, so the 
backend App A can now communicate with/access App B.

#3 exposes client credentials of App B to admins of app A — this is our 
problem. As stated in #1, we cannot make any assumptions about the level of 
trust between the two groups.

If OAuth2 provided a client credential rotation, this exposure of credentials 
can be limited to a small time window. The original client_secret can be a 
one-time-use-bootstrap, that App A backend exchanges for another secret from 
the authorization server. Generalizing it, the OAuth2 spec can provide for 
servers to trigger a client_secret rotation.

To your analogy, the front-end app can “leak” the credentials during 
provisioning (it can be a simple copy/paste that the user has to do), thus 
creating a security issue. But if the credentials are one-time-bootstrap, then 
first time the front-end app connects to Google drive, drive changes the 
client_secret for a different one, which then would be used by front-end app in 
the future. Drive also has the ability to periodically rotate the client_secret 
in a similar manner. This assumes front-end app cannot access the client_secret 
once it is provisioned.

Is this better? Thanks!

-Amarendra

--
sent via recycled electrons, from my portable command center.



> On Jul 13, 2020, at 1:48 PM, Warren Parad  wrote:
> 
> I'm not sure if it is just me, but I'm not sure I'm totally following.
> 
> I can see a concrete analogy being that, Tenant application B could be Google 
> Drive, and Tenant application A being any front end app that wants to offer a 
> service that saves files in a user's Google Drive. If application A wants to 
> interact with application B offline then tenant A needs a service 
> client/secret along with an authorization grant initiated through application 
> A (currently via UI in OAuth2).
> 
> Whether application A cycles the client secret or not seems like a different 
> problem. But I think I'm missing something. Given the example I provided, 
> would you be able to provide more insight into the problem you are seeing?
> 
> Warren Parad
> Secure your user data and complete your authorization architecture. Implement 
> Authress .
>  
> 
> On Mon, Jul 13, 2020 at 10:36 PM Amarendra Godbole 
> mailto:40broadcom@dmarc.ietf.org>> 
> wrote:
> Hi All,
> 
> First post to the list, and hopefully I am articulate enough to describe the 
> problem I am facing — did OAuth ever consider an ability to dynamically 
> rotate client secret (part of the “client credentials” authorization grant)? 
> I stumbled across rfc7591 (OAuth 2.0 Dynamic Client Registration Protocol), 
> but the OAuth 2.0 implementation I am looking at [1], does not support it. I 
> also found some previous reference to client secret rotation [2], but it does 
> not discuss my use case.
> 
> We operate a SaaS application A, which is supposed to talk with another SaaS 
> application B. Our customers subscribe to both, our application A as well as 
> application B. However, the teams adminstering A and B are separate teams 
> within the same organization, though we cannot assume the level of trust 
> between them. Let’s call them Tenant Admin A and Tenant Admin B. In our 
> usecase, application A is the client for application B, and application B 
> provides OAuth 2.0 authorization workflows. Now, Tenant Admin A has to 
> provision the "client credentials” authorization grant — in order to do that, 
> Tenant Admin B generates the client_id and client_secret, and sends them to 
> Tenant Admin B. There is the problem — as I earlier stated, we cannot assume 
> the level of trust between Tenant Admin A and Tenant Admin B, and exchanging 
> client_id and client_secret now means the circle of trust for application B 
> includes individuals who may or may not be trusted.
> 
> One thought that occured to me was a provision in OAuth 2.0’s client 
> credentials grant flow was the ability to “bootstrap” a client application — 
> basically the client_secret is one-time-use-and-timebound-only, and allows 
> the client to exchange it for a different client_secret. In our case, this 
> can be handled by the SaaS application backend, thus making sure the Tenant 
> Admin A no longer have access to it once they provision the client. This can 
> be generalized, such that the authZ server can periodically trigger 
> client_

Re: [OAUTH-WG] Rotating client secret

[Warren Parad]

I'm not sure if it is just me, but I'm not sure I'm totally following.

I can see a concrete analogy being that, Tenant application B could be
Google Drive, and Tenant application A being any front end app that wants
to offer a service that saves files in a user's Google Drive. If
application A wants to interact with application B offline then tenant A
needs a service client/secret along with an authorization grant initiated
through application A (currently via UI in OAuth2).

Whether application A cycles the client secret or not seems like a
different problem. But I think I'm missing something. Given the example I
provided, would you be able to provide more insight into the problem you
are seeing?


*Warren Parad*
Secure your user data and complete your authorization architecture.
Implement Authress .



On Mon, Jul 13, 2020 at 10:36 PM Amarendra Godbole  wrote:

> Hi All,
>
> First post to the list, and hopefully I am articulate enough to describe
> the problem I am facing — did OAuth ever consider an ability to dynamically
> rotate client secret (part of the “client credentials” authorization
> grant)? I stumbled across rfc7591 (OAuth 2.0 Dynamic Client Registration
> Protocol), but the OAuth 2.0 implementation I am looking at [1], does not
> support it. I also found some previous reference to client secret rotation
> [2], but it does not discuss my use case.
>
> We operate a SaaS application A, which is supposed to talk with another
> SaaS application B. Our customers subscribe to both, our application A as
> well as application B. However, the teams adminstering A and B are separate
> teams within the same organization, though we cannot assume the level of
> trust between them. Let’s call them Tenant Admin A and Tenant Admin B. In
> our usecase, application A is the client for application B, and application
> B provides OAuth 2.0 authorization workflows. Now, Tenant Admin A has to
> provision the "client credentials” authorization grant — in order to do
> that, Tenant Admin B generates the client_id and client_secret, and sends
> them to Tenant Admin B. There is the problem — as I earlier stated, we
> cannot assume the level of trust between Tenant Admin A and Tenant Admin B,
> and exchanging client_id and client_secret now means the circle of trust
> for application B includes individuals who may or may not be trusted.
>
> One thought that occured to me was a provision in OAuth 2.0’s client
> credentials grant flow was the ability to “bootstrap” a client application
> — basically the client_secret is one-time-use-and-timebound-only, and
> allows the client to exchange it for a different client_secret. In our
> case, this can be handled by the SaaS application backend, thus making sure
> the Tenant Admin A no longer have access to it once they provision the
> client. This can be generalized, such that the authZ server can
> periodically trigger client_secret rotation, and won’t require manual
> intervention [3]. As I stated earlier, rfc7591 talks about this, but but in
> the context of dynamic registration.
>
> Having the client secret rotation a part of the protocol exchange
> messages, maybe a bootstrap, would be the ideal solution for our usecase.
>
> Or the bigger question: Did I misinterpret it all? Looking for guidance
> from this list.
>
> Thanks in advance.
>
> -Amarendra
>
> [1] Microsoft Azure
> https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-app-types
> [2]
> https://mailarchive.ietf.org/arch/msg/oauth/7ICMSRI2tjfXDD1Bk_G-qNpLy-0/
> [3] Auth0 rotate client secret:
> https://auth0.com/docs/dashboard/guides/applications/rotate-client-secret
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Rotating client secret

[Amarendra Godbole]

Hi All,

First post to the list, and hopefully I am articulate enough to describe the 
problem I am facing — did OAuth ever consider an ability to dynamically rotate 
client secret (part of the “client credentials” authorization grant)? I 
stumbled across rfc7591 (OAuth 2.0 Dynamic Client Registration Protocol), but 
the OAuth 2.0 implementation I am looking at [1], does not support it. I also 
found some previous reference to client secret rotation [2], but it does not 
discuss my use case.

We operate a SaaS application A, which is supposed to talk with another SaaS 
application B. Our customers subscribe to both, our application A as well as 
application B. However, the teams adminstering A and B are separate teams 
within the same organization, though we cannot assume the level of trust 
between them. Let’s call them Tenant Admin A and Tenant Admin B. In our 
usecase, application A is the client for application B, and application B 
provides OAuth 2.0 authorization workflows. Now, Tenant Admin A has to 
provision the "client credentials” authorization grant — in order to do that, 
Tenant Admin B generates the client_id and client_secret, and sends them to 
Tenant Admin B. There is the problem — as I earlier stated, we cannot assume 
the level of trust between Tenant Admin A and Tenant Admin B, and exchanging 
client_id and client_secret now means the circle of trust for application B 
includes individuals who may or may not be trusted.

One thought that occured to me was a provision in OAuth 2.0’s client 
credentials grant flow was the ability to “bootstrap” a client application — 
basically the client_secret is one-time-use-and-timebound-only, and allows the 
client to exchange it for a different client_secret. In our case, this can be 
handled by the SaaS application backend, thus making sure the Tenant Admin A no 
longer have access to it once they provision the client. This can be 
generalized, such that the authZ server can periodically trigger client_secret 
rotation, and won’t require manual intervention [3]. As I stated earlier, 
rfc7591 talks about this, but but in the context of dynamic registration.

Having the client secret rotation a part of the protocol exchange messages, 
maybe a bootstrap, would be the ideal solution for our usecase.

Or the bigger question: Did I misinterpret it all? Looking for guidance from 
this list.

Thanks in advance.

-Amarendra

[1] Microsoft Azure 
https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-app-types 

[2] https://mailarchive.ietf.org/arch/msg/oauth/7ICMSRI2tjfXDD1Bk_G-qNpLy-0/ 

[3] Auth0 rotate client secret: 
https://auth0.com/docs/dashboard/guides/applications/rotate-client-secret 


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Request JSON Encoding

[Justin Richer]

It’s all good, I wrote it relatively quickly and I haven’t actually built it 
out. The idea struck me this week, as I was working on something for a client, 
that it would be a fairly simple translation from the map structure of form 
encoding to a JSON-based map structure for the same key-value pairs, and you 
could skip all the form encoding for the values and occasionally make use of a 
more native encoding method for some values like scope.

For aligning request and response, it could say that there’s an alternate 
response encoding as well but only if the client uses this request format. 
That’s a lot for the AS to track, but it would let clients speak only one 
dialect natively. It might be squirrely but then again it might just make sense 
for the AS to track it all.

Ultimately it’s a back-patch because all OAuth values are going to have to 
define form encodings and an extension couldn’t take full advantage of this 
unless it was written to be JSON-only, which would be a bit weird and limiting. 
For example, I didn’t look at applying it to PAR because the PAR values are 
defined in terms of query parameters already, and are therefore beholden to 
those rules and not the token endpoint rules. It might work there, too, but 
probably not even as smoothly as this!

I appreciate the read through and the comments! I’d be curious if there’s any 
energy in the group to pick it up.

 — Justin

> On Jul 13, 2020, at 1:00 PM, Filip Skokan  wrote:
> 
> Apologies Justin, i read it in a rush. 
> 
> But, even more so after your clarification, if the ID means responses are 
> unmodified it’s just confusing - as you say - at odds with each other, since 
> i’d send in scope as array and get it back as a string from the token 
> response. 
> 
> Odesláno z iPhonu
> 
>> 13. 7. 2020 v 18:09, Justin Richer :
>> 
>> The intent was to only affect the request, not the response, though I can 
>> see the confusion that would arise in having those be at odds with each 
>> other. 
>> 
>>  — Justin
>> 
>>> On Jul 13, 2020, at 11:47 AM, Filip Skokan >> > wrote:
>>> 
>>> Hello Justin, 
>>> 
>>> Your ID changes both how a client sends a request as well as how the, 
>>> already a json, token response is structured (as far as i can see it 
>>> changes scope from a space separated value to an array). 
>>> 
>>> The response morphing will be confusing to clients.
>>> 
>>> I don’t think there’s much to explore here, apart from 
>>> authorization_details param sent to the token endpoint form encoded i don’t 
>>> find much unnatural about the existing oauth interface. 
>>> 
>>> Filip
>>> 
>>> Odesláno z iPhonu
>>> 
 9. 7. 2020 v 21:29, Justin Richer >>> >:
 
 
 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/id/draft-richer-oauth-json-request-00.html 
 
 
 The basic idea is that you take the map of form inputs and make it into a 
 JSON object. For some fields, like scope and authorization_details, you 
 can define a JSON-specific encoding to make use of object and array 
 structures native to JSON. You also don’t have to url-encode values inside 
 the JSON strings. 
 
 Caveat, I haven’t tried implementing this yet, but I think it’s not likely 
 to be that difficult for either the client or server side of things. At 
 worst it seems like it’d be a pretty simple middleware function. 
 Functionality can be detected at the AS by the content negotiation in HTTP 
 (client sends content-type of JSON), and can be advertised as an option in 
 the metadata (or in an OPTIONS call to the token endpoint, to be more 
 HTTP-friendly).
 
  — Justin
 ___
 OAuth mailing list
 OAuth@ietf.org 
 https://www.ietf.org/mailman/listinfo/oauth 
 
>> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

[Neil Madden]

On 13 Jul 2020, at 16:44, Francis Pouatcha  wrote:
> 
>> 
>> 
>> Proof of RO (PSU) authorized interaction between the RO and the Client (TPP) 
>> prior to starting an payment authorization request is essential.
>> 
>> The NextGenPSD2 specification addresses the problem with a so-called oAuth2 
>> pre-step option. As this requires two authorization operations (SCA) for the 
>> release of a single payment, banks implementing oAuth2 pre-step fell under 
>> the scrutiny of the EBA (European Banking Association) last June. Now those 
>> banks have the burden of proving to their NCA's (national market/country 
>> authorities) that pre-step is necessary to mitigate the very problem you are 
>> raising in this thread.
> 
> I’m not sure this is the same issue I’m raising in this thread. In 
> particular, what I’m suggesting would *not* need two authorization requests 
> per payment. What I am suggesting is that there is one long-lived 
> authorization between the RO and a client and then individual authorizations 
> of each transaction: 1 + N not 2N. 
> For the first payment you will need 2 authorizations. This is what I mean 
> with the pre-step above.

Well it’s still only 1 authorization for the actual payment. The first 
authorization is the permission to initiate subsequent payment authorizations. 
I would imagine that most forms of fine-grained or transactional authorization 
will be used alongside more traditional forms of OAuth authorization, so this 
would be pretty natural in practice. For example, on first launch of an app you 
might get a consent screen like:

FooPay would like to:
 - List your accounts
 - View your account balance
 - Initiate payments from your account (you’ll be asked to approve each one)

> 
> And I understand you want to introduce grant management for the first durable 
> authorization, so RO can revoque this correct?


This is a pretty standard feature of AS software, so I’d opt for “preserve” 
rather than “introduce”.

— Neil___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Request JSON Encoding

[Filip Skokan]

Apologies Justin, i read it in a rush. 

But, even more so after your clarification, if the ID means responses are 
unmodified it’s just confusing - as you say - at odds with each other, since 
i’d send in scope as array and get it back as a string from the token response. 

Odesláno z iPhonu

> 13. 7. 2020 v 18:09, Justin Richer :
> 
> The intent was to only affect the request, not the response, though I can 
> see the confusion that would arise in having those be at odds with each 
> other. 
> 
>  — Justin
> 
>>> On Jul 13, 2020, at 11:47 AM, Filip Skokan  wrote:
>>> 
>>> Hello Justin, 
>>> 
>>> Your ID changes both how a client sends a request as well as how the, 
>>> already a json, token response is structured (as far as i can see it 
>>> changes scope from a space separated value to an array). 
>>> 
>>> The response morphing will be confusing to clients.
>>> 
>>> I don’t think there’s much to explore here, apart from 
>>> authorization_details param sent to the token endpoint form encoded i don’t 
>>> find much unnatural about the existing oauth interface. 
>>> 
>>> Filip
>>> 
>>> Odesláno z iPhonu
>>> 
>>> 9. 7. 2020 v 21:29, Justin Richer :
>>> 
>>> 
>>> 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/id/draft-richer-oauth-json-request-00.html
>>> 
>>> The basic idea is that you take the map of form inputs and make it into a 
>>> JSON object. For some fields, like scope and authorization_details, you can 
>>> define a JSON-specific encoding to make use of object and array structures 
>>> native to JSON. You also don’t have to url-encode values inside the JSON 
>>> strings. 
>>> 
>>> Caveat, I haven’t tried implementing this yet, but I think it’s not likely 
>>> to be that difficult for either the client or server side of things. At 
>>> worst it seems like it’d be a pretty simple middleware function. 
>>> Functionality can be detected at the AS by the content negotiation in HTTP 
>>> (client sends content-type of JSON), and can be advertised as an option in 
>>> the metadata (or in an OPTIONS call to the token endpoint, to be more 
>>> HTTP-friendly).
>>> 
>>>  — Justin
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
> 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Request JSON Encoding

[Tom Jones]

ahh - thx - so that explains why RFC 6749 OAuth 2.0 is ambiguous on the
topic. I suspect that means that GNAP will take a dependency on 8259,
Peace ..tom


On Mon, Jul 13, 2020 at 8:34 AM Carsten Bormann  wrote:

> On 2020-07-13, at 17:19, Tom Jones  wrote:
> >
> > What, exactly is json encoding?
>
> JSON is defined in RFC 8259.
> The term “encoding” is ambiguous here, it could be used for the encoding
> of a JSON text (which employs UTF-8) or the representation of an
> application data model using the JSON generic data model.
>
> > It sounds like a python or java method.
>
> Many languages and platforms support JSON.
>
> > Afaik json can be encoded in utf 8 16 or 32.
>
> Early definitions of JSON said so, even though that practically never
> happened in interchange.  RFC 8259 supports UTF-8 encoding only.
>
> Grüße, Carsten
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Request JSON Encoding

[Justin Richer]

The intent was to only affect the request, not the response, though I can see 
the confusion that would arise in having those be at odds with each other. 

 — Justin

> On Jul 13, 2020, at 11:47 AM, Filip Skokan  wrote:
> 
> Hello Justin, 
> 
> Your ID changes both how a client sends a request as well as how the, already 
> a json, token response is structured (as far as i can see it changes scope 
> from a space separated value to an array). 
> 
> The response morphing will be confusing to clients.
> 
> I don’t think there’s much to explore here, apart from authorization_details 
> param sent to the token endpoint form encoded i don’t find much unnatural 
> about the existing oauth interface. 
> 
> Filip
> 
> Odesláno z iPhonu
> 
>> 9. 7. 2020 v 21:29, Justin Richer :
>> 
>> 
>> 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/id/draft-richer-oauth-json-request-00.html 
>> 
>> 
>> The basic idea is that you take the map of form inputs and make it into a 
>> JSON object. For some fields, like scope and authorization_details, you can 
>> define a JSON-specific encoding to make use of object and array structures 
>> native to JSON. You also don’t have to url-encode values inside the JSON 
>> strings. 
>> 
>> Caveat, I haven’t tried implementing this yet, but I think it’s not likely 
>> to be that difficult for either the client or server side of things. At 
>> worst it seems like it’d be a pretty simple middleware function. 
>> Functionality can be detected at the AS by the content negotiation in HTTP 
>> (client sends content-type of JSON), and can be advertised as an option in 
>> the metadata (or in an OPTIONS call to the token endpoint, to be more 
>> HTTP-friendly).
>> 
>>  — Justin
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Request JSON Encoding

[Filip Skokan]

Hello Justin, 

Your ID changes both how a client sends a request as well as how the, already a 
json, token response is structured (as far as i can see it changes scope from a 
space separated value to an array). 

The response morphing will be confusing to clients.

I don’t think there’s much to explore here, apart from authorization_details 
param sent to the token endpoint form encoded i don’t find much unnatural about 
the existing oauth interface. 

Filip

Odesláno z iPhonu

> 9. 7. 2020 v 21:29, Justin Richer :
> 
> 
> 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/id/draft-richer-oauth-json-request-00.html
> 
> The basic idea is that you take the map of form inputs and make it into a 
> JSON object. For some fields, like scope and authorization_details, you can 
> define a JSON-specific encoding to make use of object and array structures 
> native to JSON. You also don’t have to url-encode values inside the JSON 
> strings. 
> 
> Caveat, I haven’t tried implementing this yet, but I think it’s not likely to 
> be that difficult for either the client or server side of things. At worst it 
> seems like it’d be a pretty simple middleware function. Functionality can be 
> detected at the AS by the content negotiation in HTTP (client sends 
> content-type of JSON), and can be advertised as an option in the metadata (or 
> in an OPTIONS call to the token endpoint, to be more HTTP-friendly).
> 
>  — Justin
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

[Francis Pouatcha]

>
> Proof of RO (PSU) authorized interaction between the RO and the Client
> (TPP) prior to starting an payment authorization request is essential.
>
> The NextGenPSD2 specification addresses the problem with a so-called
> oAuth2 pre-step option. As this requires two authorization operations (SCA)
> for the release of a single payment, banks implementing oAuth2 pre-step
> fell under the scrutiny of the EBA (European Banking Association) last
> June. Now those banks have the burden of proving to their NCA's (national
> market/country authorities) that pre-step is necessary to mitigate the very
> problem you are raising in this thread.
>
>
> I’m not sure this is the same issue I’m raising in this thread. In
> particular, what I’m suggesting would *not* need two authorization requests
> per payment. What I am suggesting is that there is one long-lived
> authorization between the RO and a client and then individual
> authorizations of each transaction: 1 + N not 2N.
>
For the first payment you will need 2 authorizations. This is what I mean
with the pre-step above.

And I understand you want to introduce grant management for the first
durable authorization, so RO can revoque this correct?

>
>

>
> Let settle with:
> - RAR as a payload for carrying authorization details
> - The decision on whether to protect an authorization transaction with a
> preceding RO authorization to do so shall be left to the target oAuth2
> profile.
>
>
> On Thu, Jul 9, 2020 at 1:58 PM Neil Madden 
> wrote:
>
>>
>> > 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?
>> >>
>> >> “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
>> relationship with can’t just send me a request to transfer $500 to some
>> account.
>> >
>> > Are we talking about legal consent or a security measures here?
>> 
>>  Normal OAuth consent. My phone is my resource, and I am its
>> resource owner. If a client wants to send payment requests to my phone
>> (e.g. via CIBA backchannel) then it should have to get my permission first.
>> Even without backchannel requests, I’d much rather that only the three
>> clients I’ve explicitly consented to can ask me to initiate payments rather
>> than the hundreds/thousands clients my bank happens to have a relationship
>> with.
>> >>>
>> >>> To me it sounds like you would like to require a client to get
>> user authorization to send an authorization request. Would you require the
>> same if I would use scope values to encode a payment initiation request?
>> >>
>> >> Yes. If something is sufficiently high value to require
>> per-transaction authorization then initiating transactions itself becomes a
>> privileged operation.
>> >
>> > The per transaction authorization alone is a significant increase
>> in security. What is the added value of requiring an authorization to send
>> a per-transaction authorisation request in an additional step?
>> 
>>  Because Open Banking allows any client at any time to send an
>> asynchronous back channel request to my phone to approve a payment. This is
>> pretty risky.
>> >>>
>> >>> Can you please explain how you came to that conclusion and how it
>> relates to RAR?
>> >>
>> >>
>> https://openbankinguk.github.io/read-write-api-site3/v3.1.6/profiles/payment-initiation-api-profile.html
>> >>
>> >> Client (PISP) initiates a payment-order consent using a
>> client_credentials access token, then launches a CIBA backchannel
>> authorization request. What prevents this?
>> >
>> > The fact that the PISP cannot issue this request without a valid user
>> identifier. The demos I’m remembering use a traditional first authorization
>> flow to establish this identifier.
>>
>> An identifier is not an access token or credential.
>>
>> >>
>> >> This relates to RAR, because RAR also has no protection against this.
>> If you use RAR in combination with a backchannel authorization method then
>> the same issue applies. This is a general issue with backchannel approaches,
>> >
>> > Exactly! It's a problem with any kind of backchannel initiated _user
>> interaction_.
>> >
>> >
>> >> but it is particularly a risk here because RAR is pitching itself as a
>> way to do payment transactions.
>> >
>> > The problem is the backchannel request, not RAR. RAR is just a more
>> elaborated scope.
>>
>> I don’t agree. It’s particularly acute with backchannel requests, but it
>> still exists with front channel. If I can redirect your browser to a
>> payment confirmation screen, what percentage of users will click ok? I
>> would guess more than 0. It’s a pro

Re: [OAUTH-WG] OAuth Request JSON Encoding

[Carsten Bormann]

On 2020-07-13, at 17:19, Tom Jones  wrote:
> 
> What, exactly is json encoding?

JSON is defined in RFC 8259.
The term “encoding” is ambiguous here, it could be used for the encoding of a 
JSON text (which employs UTF-8) or the representation of an application data 
model using the JSON generic data model.

> It sounds like a python or java method.

Many languages and platforms support JSON.

> Afaik json can be encoded in utf 8 16 or 32.

Early definitions of JSON said so, even though that practically never happened 
in interchange.  RFC 8259 supports UTF-8 encoding only.

Grüße, Carsten

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Request JSON Encoding

[Tom Jones]

What, exactly is json encoding? It sounds like a python or java method.
Afaik json can be encoded in utf 8 16 or 32. But form encoding is limited
to ascii or even to base64url
.. Is that the point. Will GNAP specify one encoding?

thx ..Tom (mobile)

On Thu, Jul 9, 2020, 12:29 PM Justin Richer  wrote:

> 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/id/draft-richer-oauth-json-request-00.html
>
> The basic idea is that you take the map of form inputs and make it into a
> JSON object. For some fields, like scope and authorization_details, you can
> define a JSON-specific encoding to make use of object and array structures
> native to JSON. You also don’t have to url-encode values inside the JSON
> strings.
>
> Caveat, I haven’t tried implementing this yet, but I think it’s not likely
> to be that difficult for either the client or server side of things. At
> worst it seems like it’d be a pretty simple middleware function.
> Functionality can be detected at the AS by the content negotiation in HTTP
> (client sends content-type of JSON), and can be advertised as an option in
> the metadata (or in an OPTIONS call to the token endpoint, to be more
> HTTP-friendly).
>
>  — Justin
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

[Neil Madden]

> On 13 Jul 2020, at 09:29, Torsten Lodderstedt  wrote:
> 
> 
> 
>> On 9. Jul 2020, at 19:58, Neil Madden  wrote:
>> 
>> The point is that RAR can’t make payment transactions the primary use-case, 
>> emphasised throughout the draft, and then fail to even discuss this issue or 
>> make any kind of suggestion as how to handle it. 
> 
> I’m still trying to understand the issue and your proposed solution. What you 
> are suggesting is an OAuth authorization to subsequently send another more 
> detailed or transactional OAuth authorization. 
> 
> If your basic assumption is that users just accept a payment conformation 
> screen, why do you think the additional pre-authorization won’t be accepted 
> straight away?

It’s not about having two authorization screens. It’s about allowing users to 
manage their relationship with a client just as they can for any other OAuth 
client. If a normal OAuth client behaves badly I can go and revoke my grant of 
access to that client. I can’t do that with the transactional uses of RAR 
because each one is a blank slate. 

Having individual transactions tied to an overall grant of authority lets the 
user control which clients they interact with and which they trust. 

To me, this (user consent and control) is a fundamental strength of OAuth and 
any approach to transactional authorization using OAuth should preserve this. 

The other point I was making is that when the transactional authorization 
occurs over a backchannel then it is much better if the user has previously 
explicitly authorized that client over a front channel - eg when they first 
installed an app. I’m not suggesting that the AS would send two backchannel 
authorization requests instead of one. 

> 
> The way PSD2 uses to secure such transactions is transaction authorization 
> using a dynamic second factor (called strong customer authentication). I 
> assume the rational is SCA will make users think before they confirm. 

I hope so. But given that authN usually occurs before the consent stage, the 
user may not know what it is they are consenting to before they complete 2FA. 

— Neil

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

[Neil Madden]

> On 13 Jul 2020, at 01:52, Francis Pouatcha  wrote:
> 
> 
> Hi Neil,
> 
> IMHO the purpose of RAR is to provide a rich substitute for oAuth2 scopes.
> 
> The point you are addressing in this thread is nevertheless very pertinent, 
> even though not directly related to RAR. 

I think it is absolutely related. 

> 
> Proof of RO (PSU) authorized interaction between the RO and the Client (TPP) 
> prior to starting an payment authorization request is essential.
> 
> The NextGenPSD2 specification addresses the problem with a so-called oAuth2 
> pre-step option. As this requires two authorization operations (SCA) for the 
> release of a single payment, banks implementing oAuth2 pre-step fell under 
> the scrutiny of the EBA (European Banking Association) last June. Now those 
> banks have the burden of proving to their NCA's (national market/country 
> authorities) that pre-step is necessary to mitigate the very problem you are 
> raising in this thread.

I’m not sure this is the same issue I’m raising in this thread. In particular, 
what I’m suggesting would *not* need two authorization requests per payment. 
What I am suggesting is that there is one long-lived authorization between the 
RO and a client and then individual authorizations of each transaction: 1 + N 
not 2N. 

> 
> Let settle with:
> - RAR as a payload for carrying authorization details
> - The decision on whether to protect an authorization transaction with a 
> preceding RO authorization to do so shall be left to the target oAuth2 
> profile.
> 
>> On Thu, Jul 9, 2020 at 1:58 PM Neil Madden  wrote:
>> 
>> > 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?
>> >> 
>> >> “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 
>> >> relationship with can’t just send me a request to transfer $500 
>> >> to some account. 
>> > 
>> > Are we talking about legal consent or a security measures here?
>>  
>>  Normal OAuth consent. My phone is my resource, and I am its 
>>  resource owner. If a client wants to send payment requests to my 
>>  phone (e.g. via CIBA backchannel) then it should have to get my 
>>  permission first. Even without backchannel requests, I’d much 
>>  rather that only the three clients I’ve explicitly consented to can 
>>  ask me to initiate payments rather than the hundreds/thousands 
>>  clients my bank happens to have a relationship with.
>> >>> 
>> >>> To me it sounds like you would like to require a client to get user 
>> >>> authorization to send an authorization request. Would you require 
>> >>> the same if I would use scope values to encode a payment initiation 
>> >>> request?
>> >> 
>> >> Yes. If something is sufficiently high value to require 
>> >> per-transaction authorization then initiating transactions itself 
>> >> becomes a privileged operation. 
>> > 
>> > The per transaction authorization alone is a significant increase in 
>> > security. What is the added value of requiring an authorization to 
>> > send a per-transaction authorisation request in an additional step?
>>  
>>  Because Open Banking allows any client at any time to send an 
>>  asynchronous back channel request to my phone to approve a payment. 
>>  This is pretty risky. 
>> >>> 
>> >>> Can you please explain how you came to that conclusion and how it 
>> >>> relates to RAR?
>> >> 
>> >> https://openbankinguk.github.io/read-write-api-site3/v3.1.6/profiles/payment-initiation-api-profile.html
>> >> 
>> >> Client (PISP) initiates a payment-order consent using a 
>> >> client_credentials access token, then launches a CIBA backchannel 
>> >> authorization request. What prevents this?
>> > 
>> > The fact that the PISP cannot issue this request without a valid user 
>> > identifier. The demos I’m remembering use a traditional first 
>> > authorization flow to establish this identifier.
>> 
>> An identifier is not an access token or credential.
>> 
>> >> 
>> >> This relates to RAR, because RAR also has no protection against this. If 
>> >> you use RAR in combination with a backchannel authorization method then 
>> >> the same issue applies. This is a general issue with backchannel 
>> >> approaches,
>> > 
>> > Exactly! It's a problem with any kind of backchannel initiated _user 
>> > interaction_. 
>> > 
>> > 
>> >> but it is particularly a risk here because RAR is pitching itself as a 
>> >> way to do payment transactions.
>> > 
>> > The problem is the backchannel

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

[Torsten Lodderstedt]

> On 9. Jul 2020, at 19:58, Neil Madden  wrote:
> 
> The point is that RAR can’t make payment transactions the primary use-case, 
> emphasised throughout the draft, and then fail to even discuss this issue or 
> make any kind of suggestion as how to handle it. 

I’m still trying to understand the issue and your proposed solution. What you 
are suggesting is an OAuth authorization to subsequently send another more 
detailed or transactional OAuth authorization. 

If your basic assumption is that users just accept a payment conformation 
screen, why do you think the additional pre-authorization won’t be accepted 
straight away?

The way PSD2 uses to secure such transactions is transaction authorization 
using a dynamic second factor (called strong customer authentication). I assume 
the rational is SCA will make users think before they confirm. 



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