Subject: [OAUTH-WG] Transaction Authorization with OAuth

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 20 Apr 2019 20:21:26 +0200

Hi all, 

I just published an article about the subject at: https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948  

I look forward to getting your feedback.

kind regards,
Torsten.

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sun, 21 Apr 2019 23:41:20 +0300

The proposed structured_scope fits nicely into the JSON object format of
the request object.

At present for similar cases we recommend developers to encode the scope
value into a URI with query string parameters, e.g.

https://scopes.myapp.com/sign?credentialID=qes_eidas&documentDigests.hash=sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI&documentDigests.label=Mobile%20Subscription%20Contract&hashAlgorithmOID=2.16.840.1.101.3.4.2.1

---

From: Steinar Noem <[email-masked]>
Date: Mon, 22 Apr 2019 10:38:31 +0200

Hi Torsten, thank you for writing this clarifying article :)

In the health sector in Norway we are facing similar challenges regarding
the need for contextual information.
At the time, our planned solution is to package this information as custom
claims in request objects - e.g.: “helse:client/claims/xxxx”, but after
reading your article I realize that the structured scope approach makes a
lot more sense and, as you stated in the article, pushing the request
objects mitigates the issues with request-size and complexity on the client
side.
In our case we may also have a requirement to encrypt the pushed request
object due to potential sensitive content.

- Steinar

lør. 20. apr. 2019 kl. 20:21 skrev Torsten Lodderstedt <
[email-masked]>:

> Hi all,
>
> I just published an article about the subject at:
> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| [email-masked] | [email-masked]  | +47 955 21 620 | www.udelt.no |

---

From: Pedro Igor Silva <[email-masked]>
Date: Mon, 22 Apr 2019 11:34:50 -0300

Hi Torsten,

Great article, thanks for sharing it.

We have been working on a solution for fine-grained authorization using
OAuth2 but specific for first-party applications where the granted
permissions/scopes depend on the policies associated with the
resources/scopes a client is trying to access. We don't have extensions to
the authorization endpoint but a specific grant type for this purpose on
the token endpoint.

The solution is similar to the Lodging Intent Pattern but also based on
specific parts of UMA and ACE.

Basically, when a client first tries to access a protected resource the RS
will respond with all the information the client needs to obtain a valid
token from the AS. The information returned by the RS can be a
signed/encrypted JWT or just a reference that later the AS can use to
actually fetch the information. With this information in hands, clients can
then approach the AS in order to obtain an access token with the
permissions to access the protected resource.

The general idea is to empower RSs so that they can communicate to the AS
how access to their resources should be granted as well as decoupling
clients and RSs so that clients don't need to know the constraints imposed
by the RS to their protected resources (e.g. scopes).

I've started to write a document with this idea in mind and I'm happy to
share it with you and see what you think.

Best regards.
Pedro Igor

---

From: Jim Manico <[email-masked]>
Date: Mon, 22 Apr 2019 11:10:58 -0500

Have you looked at other standards that address find grained access control like NIST ABAC or XACML? This is a somewhat solved issue and I wonder if previous work can be leveraged. 

A basic string “scope” is certainly not enough to represent and transport complex authorization policy. I would imagine that something closer to XACML would work.

--
Jim Manico
@Manicode

> On Apr 22, 2019, at 9:34 AM, Pedro Igor Silva <[email-masked]> wrote:
> 
> Hi Torsten,
> 
> We have been working on a solution for fine-grained authorization using OAuth2 but specific for first-party applications where the granted permissions/scopes depend on the policies associated with the resources/scopes a client is trying to access. We don't have extensions to the authorization endpoint but a specific grant type for this purpose on the token endpoint.
> 
> The solution is similar to the Lodging Intent Pattern but also based on specific parts of UMA and ACE.
> 
> Basically, when a client first tries to access a protected resource the RS will respond with all the information the client needs to obtain a valid token from the AS. The information returned by the RS can be a signed/encrypted JWT or just a reference that later the AS can use to actually fetch the information. With this information in hands, clients can then approach the AS in order to obtain an access token with the permissions to access the protected resource.
> 
> The general idea is to empower RSs so that they can communicate to the AS how access to their resources should be granted as well as decoupling clients and RSs so that clients don't need to know the constraints imposed by the RS to their protected resources (e.g. scopes). 
> 
> I've started to write a document with this idea in mind and I'm happy to share it with you and see what you think.
> 
> Best regards.
> Pedro Igor
> 
>> On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt <[email-masked]> wrote:
>> Hi all, 
>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 22 Apr 2019 18:29:13 +0200

HI Steinar,

> On 22. Apr 2019, at 10:38, Steinar Noem <[email-masked]> wrote:
> 

Pleasure :-)

> 
> In the health sector in Norway we are facing similar challenges regarding the need for contextual information.
> At the time, our planned solution is to package this information as custom claims in request objects - e.g.: “helse:client/claims/xxxx”,

and do not forget: claims in a request object means you force your client and AS to turn on OpenID Connect for your requests (scope openid, ID Token, ...) even if you “just” want to authorise API access. 

> but after reading your article I realize that the structured scope approach makes a lot more sense and, as you stated in the article, pushing the request objects mitigates the issues with request-size and complexity on the client side.
> In our case we may also have a requirement to encrypt the pushed request object due to potential sensitive content.

TLS is not enough?

kind regards,
Torsten. 

> 
> - Steinar
> 
> 
> lør. 20. apr. 2019 kl. 20:21 skrev Torsten Lodderstedt <[email-masked]>:
> Hi all, 
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 22 Apr 2019 18:33:50 +0200

Hi Pedro,

> On 22. Apr 2019, at 16:34, Pedro Igor Silva <[email-masked]> wrote:
> 
> Hi Torsten,
> 

my pleasure :-)

> The general idea is to empower RSs so that they can communicate to the AS how access to their resources should be granted as well as decoupling clients and RSs so that clients don't need to know th…

Sounds very much like UMA2. The difference I see is the RS needs to be heavily involved in the authorization process (whereas the approaches I discussed leave it passive). How would you handle the use cases I described? So for example, how would you construct the JWT for the signature use case? I’m asking because the signing case uses more data in the authorization process and might bundle the request to sign multiple documents, even if the first signing request would only need the hashes or even just a single hash of a document. 

> I've started to write a document with this idea in mind and I'm happy to share it with you and see what you think.

Look forward to reading your article. 

best regards,
Torsten.

---

From: Pedro Igor Silva <[email-masked]>
Date: Mon, 22 Apr 2019 13:35:18 -0300

Yeah, I did.

XACML is a good standard, even better after v3. We do have options to
leverage XACML policy language model to write policies, but protocol-wise,
something on top of OAuth, would be very nice. As an authorization
framework, fine-grained/contextual authorization seems to be a natural
addition to OAuth.

Regards.
Pedro Igor

On Mon, Apr 22, 2019 at 1:11 PM Jim Manico <[email-masked]> wrote:

> Have you looked at other standards that address find grained access
> control like NIST ABAC or XACML? This is a somewhat solved issue and I
> wonder if previous work can be leveraged.
>
> A basic string “scope” is certainly not enough to represent and transport
> complex authorization policy. I would imagine that something closer to
> XACML would work.
>
> --
> Jim Manico
> @Manicode
>
> On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt <
> [email-masked] <torsten@lodderstedt..net>> wrote:
>
>> Hi all,
>>
>> <https://medium..com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948>
>>
>>

---

From: Pedro Igor Silva <[email-masked]>
Date: Mon, 22 Apr 2019 13:58:14 -0300

On Mon, Apr 22, 2019 at 1:33 PM Torsten Lodderstedt <[email-masked]>
wrote:

> > Basically, when a client first tries to access a protected resource the
> RS will respond with all the information the client needs to obtain a valid
> > The general idea is to empower RSs so that they can communicate to the
> AS how access to their resources should be granted as well as decoupling
> Sounds very much like UMA2. The difference I see is the RS needs to be
> heavily involved in the authorization process (whereas the approaches I
> discussed leave it passive). How would you handle the use cases I
> described? So for example, how would you construct the JWT for the
> signature use case? I’m asking because the signing case uses more data in
> the authorization process and might bundle the request to sign multiple
> documents, even if the first signing request would only need the hashes or
> even just a single hash of a document.
>

Yes, it does. Like I mentioned, the model is based on UMA (Permission
Ticket/API) as well as ACE (Unauthorized Resource Request Message). I had
talked with UMA WG in the past about this solution and how we extended the
specs to solve this type of problem.

By being active during the authorization process the RS is in control over
additional claims that should be considered by the policies when making
decisions about the resources/scopes a client/user can access. Where the
information could be obtained from different sources such as the current
HTTP request or internally/externally to the RS.

We did not have much demand for addressing the signature use case, but use
cases similar to the "payment" use case. As I mentioned, the model I'm
talking about is not based on user consent. But considering that you can
also pass any information to the AS, you should be able to let users to
authorize the creation of signatures for one or more documents.

> [email-masked]> wrote:
> > Hi all,
> >

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 22 Apr 2019 19:18:36 +0200

Hi Pedro,

> Yes, it does. Like I mentioned, the model is based on UMA (Permission Ticket/API) as well as ACE (Unauthorized Resource Request Message). I had talked with UMA WG in the past about this solution and how we extended the specs to solve this type of problem.
> 
> By being active during the authorization process the RS is in control over additional claims that should be considered by the policies when making decisions about the resources/scopes a client/user can access. Where the information could be obtained from different sources such as the current HTTP request or internally/externally to the RS.

The problem from my perspective (and my understanding of UMA) is the RS does not have any information about the context of the request. For example, the client might be calling a certain resource (list of accounts) and immediately afterwards wants to obtain the balances and initiate a payment. I think the UMA case the RS either predicts this based on policy or past behaviour of the client OR the client will need to issue several token requests. That might not be a problem in 1st party scenarios but it is in 3rd party scenarios if the AS gathers consent. 

> 
> We did not have much demand for addressing the signature use case, but use cases similar to the "payment" use case. As I mentioned, the model I'm talking about is not based on user consent.

Right, you mentioned it is intended to be used for 1st parties only. 

> But considering that you can also pass any information to the AS, you should be able to let users to authorize the creation of signatures for one or more documents.

I think the client needs to pass this information, which brings us back to the original question of my article. 

best regards. 
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 22 Apr 2019 19:31:00 +0200

Hi Jim, 

thanks for pointing this out. 

Basically, what I’m proposing is not a new language for describing authorization policies. It’s more like the container to carry the data needed to inform the user about the intention of the client to the authorisation server. This container may contain anything - preferable expressed as JSON :-). But let’s ignore this for a moment. 

As OAuth is about delegating access rights to a client, the question is whether XAML could express delegation as well. If that’s the case and the AS maintains the permissions of its users as XAML policy one could potentially express the requested permissions as a subset of the users permissions. 

In the (consumer) use cases I’m typically dealing with, the user’s permission is determined by possession. So a user is in possession of an email account because it signed up for that service (and potentially pays for it). My feeling is XAML is more targeted towards enterprise use cases. 

best regards,
Torsten. 

> On 22. Apr 2019, at 18:10, Jim Manico <[email-masked]> wrote:
>

---

From: Pedro Igor Silva <[email-masked]>
Date: Mon, 22 Apr 2019 14:51:28 -0300

On Mon, Apr 22, 2019 at 2:18 PM Torsten Lodderstedt <[email-masked]>
wrote:

> > By being active during the authorization process the RS is in control
> over additional claims that should be considered by the policies when
> making decisions about the resources/scopes a client/user can access. Where
> the information could be obtained from different sources such as the
> current HTTP request or internally/externally to the RS.
>
> The problem from my perspective (and my understanding of UMA) is the RS
> does not have any information about the context of the request. For
> example, the client might be calling a certain resource (list of accounts)
> and immediately afterwards wants to obtain the balances and initiate a
> payment. I think the UMA case the RS either predicts this based on policy
> or past behaviour of the client OR the client will need to issue several
> token requests. That might not be a problem in 1st party scenarios but it
> is in 3rd party scenarios if the AS gathers consent.
>

Yeah, we are talking about different use cases. But they are still quite
related in regards to enriching authorization decisions. it would be nice
to have something in OAuth that could address both 1st and 3rd party use
cases. As I said before, the model I'm talking about is kind of a 1st party
Lodging_Intent.

Just to clarify, UMA does not cover the scenario I'm talking about although
it provides a very good ground for extensions like this. It is not part of
UMA scope. It provides much more than that too ...

>
> >
> > We did not have much demand for addressing the signature use case, but
> use cases similar to the "payment" use case. As I mentioned, the model I'm
> talking about is not based on user consent.
>
> > But considering that you can also pass any information to the AS, you
> should be able to let users to authorize the creation of signatures for one
> or more documents.
>
> > > I've started to write a document with this idea in mind and I'm happy
> to share it with you and see what you think.
> > >
> >

---

From: Pedro Igor Silva <[email-masked]>
Date: Mon, 22 Apr 2019 14:54:25 -0300

Sorry. I mean, UMA provides much more than this 1st party authorization
flow I'm talking about ....

On Mon, Apr 22, 2019 at 2:51 PM Pedro Igor Silva <[email-masked]> wrote:

>
>
> On Mon, Apr 22, 2019 at 2:18 PM Torsten Lodderstedt <
>> > > The general idea is to empower RSs so that they can communicate to
>> the AS how access to their resources should be granted as well as
>> decoupling clients and RSs so that clients don't need to know the
>> constraints imposed by the RS to their protected resources (e.g. scopes).
>> >
> Just to clarify, UMA does not cover the scenario I'm talking about
> although it provides a very good ground for extensions like this. It is not
> part of UMA scope. It provides much more than that too ...
>
>
>>
>> >

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 22 Apr 2019 20:18:55 +0200

> Am 22.04.2019 um 19:54 schrieb Pedro Igor Silva <[email-masked]>:
> 
> Sorry. I mean, UMA provides much more than this 1st party authorization flow I'm talking about .... 

got it ;-)

>>> On Mon, Apr 22, 2019 at 2:18 PM Torsten Lodderstedt <[email-masked]> wrote:
>>> Hi Pedro,
>>> 
>>> > 
>> Yeah, we are talking about different use cases. But they are still quite related in regards to enriching authorization decisions. it would be nice to have something in OAuth that could address both 1st and 3rd party use cases. As I said before, the model I'm talking about is kind of a 1st party Lodging_Intent.
>> 
>> Just to clarify, UMA does not cover the scenario I'm talking about although it provides a very good ground for extensions like this. It is not part of UMA scope. It provides much more than that too ...
>>  
>>> 
>>> >

---

From: Sascha Preibisch <[email-masked]>
Date: Mon, 22 Apr 2019 11:34:45 -0700

Thank you for the article, Torsten!

I like that 'scope' is out of the game for these kinds of authorizations.

What I can see for the general use case is a required identifier
within the 'structures_scope' document that identifies the profile it
should be used for.

Thank you,
Sascha

---

From: George Fletcher <[email-masked]>
Date: Mon, 22 Apr 2019 15:03:57 -0400

Speaking just to the UMA side of things...

...it's possible in UMA 2 for the client to request additional scopes 
when interacting with the token endpoint specifically to address cases 
where the client knows it's going to make the following requests and 
wants to obtain a token with sufficient privilege for those requests. 
This requires a fair amount of knowledge by the client of the ecosystem 
but that is sometimes the case and hence this capability exists :)

---

From: Pedro Igor Silva <[email-masked]>
Date: Mon, 22 Apr 2019 16:36:12 -0300

I think this knowledge by clients of the ecosystem is something that a
transactional authorization could avoid. Both UMA and ACE have solutions
that make clients really dumb about what they need to send to the AS in
regards to scopes. IMO, the RS should have the possibility to tell clients
the scope they need, making a lot easier to change RS's access constraints
as well as pushing contextual information that could eventually enrich the
authorization process.

On Mon, Apr 22, 2019 at 4:04 PM George Fletcher <[email-masked]> wrote:

> ...it's possible in UMA 2 for the client to request additional scopes when
> interacting with the token endpoint specifically to address cases where the
> client knows it's going to make the following requests and wants to obtain
> a token with sufficient privilege for those requests. This requires a fair
> amount of knowledge by the client of the ecosystem but that is sometimes
> the case and hence this capability exists :)
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 23 Apr 2019 07:04:27 +0200

Does UMA use the standard scope parameter?

> Am 22.04.2019 um 21:03 schrieb George Fletcher <[email-masked]>:
> 
> ...it's possible in UMA 2 for the client to request additional scopes when interacting with the token endpoint specifically to address cases where the client knows it's going to make the following requests and wants to obtain a token with sufficient privilege for those requests. This requires a fair amount of knowledge by the client of the ecosystem but that is sometimes the case and hence this capability exists :)
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 23 Apr 2019 07:06:24 +0200

Hi Sascha,

> Am 22.04.2019 um 20:34 schrieb Sascha Preibisch <[email-masked]>:
> 

my pleasure :-) 

> within the 'structures_scope' document that identifies the profile it

What does profile mean in this context?

best regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 23 Apr 2019 07:24:05 +0200

Thanks for sharing this recommendation!

> Am 21.04.2019 um 22:41 schrieb Vladimir Dzhuvinov <[email-masked]>:
>

---

From: Steinar Noem <[email-masked]>
Date: Tue, 23 Apr 2019 13:19:01 +0200

Ah, I hadn't considered the OpenId Connect/claims connection. At one point
we actually considered using the private_key_jwt client secret to transport
"claims" from the client to the AS - so we were happy to learn about the
JAR spec.

In my opinion TLS is good enough, but some security analysts and data
protection officers in the health sector may not agree with me :)
Our main use case for OAuth is interoperability between businesses on a
national level (hospitals, primary health care etc), where a health
personel requests information about a patient in a different legal entity
(business) than where they are employed.
It's a complex domain, in certain cases the combination of two personal
identifiers can be considered sensitive alone (e.g. a psychiatrist and
patient combination). But, we have seen a "softening" of the requirements
for confidentiality - so hopefully signatures will be sufficient..

- S

man. 22. apr. 2019 kl. 18:29 skrev Torsten Lodderstedt <
[email-masked]>:

> > In the health sector in Norway we are facing similar challenges
> regarding the need for contextual information.
> > At the time, our planned solution is to package this information as
> custom claims in request objects - e.g.: “helse:client/claims/xxxx”,
>
> and do not forget: claims in a request object means you force your client
> and AS to turn on OpenID Connect for your requests (scope openid, ID Token,
> ...) even if you “just” want to authorise API access.
>
> > but after reading your article I realize that the structured scope
> approach makes a lot more sense and, as you stated in the article, pushing
> the request objects mitigates the issues with request-size and complexity
> on the client side.

-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

---

From: George Fletcher <[email-masked]>
Date: Tue, 23 Apr 2019 07:32:21 -0400

Yes, from 3.3.1 of the UMA OAuth2 grant...

scope
    OPTIONAL. A string of space-separated values representing requested
    scopes. For the authorization server to consider any requested scope
    in its assessment, the client MUST have pre-registered the same
    scope with the authorization server. The client should consult the
    resource server's API documentation for details about which scopes
    it can expect the resource server's initial returned permission
    ticket to represent as part of the authorization assessment (see
    Section 3.3.4
    <https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html#authorization-assessment>).

https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html#seek-authorization

On 4/23/19 1:04 AM, Torsten Lodderstedt wrote:
> Am 22.04.2019 um 21:03 schrieb George Fletcher <[email-masked] 
> <mailto:[email-masked]>>:
>
>> when interacting with the token endpoint specifically to address 
>> cases where the client knows it's going to make the following 
>> requests and wants to obtain a token with sufficient privilege for 
>> those requests. This requires a fair amount of knowledge by the 
>> client of the ecosystem but that is sometimes the case and hence this 
>> capability exists :)
>>

---

From: George Fletcher <[email-masked]>
Date: Tue, 23 Apr 2019 07:33:20 -0400

I can see use cases where both approaches are useful. I was just 
pointing out that while the RS might not be told the context of the 
request from the client's perspective, the client still knows it's own 
context and can leverage that with UMA at the RS to reduce the need to 
request multiple tokens (which is the issue I understood Torsten to be 
making).

I would also say that in UMA there is some desire to reduce the work the 
RS has to do as well where in Torsten's use case, the RS may be managing 
all the responsibility (for good or ill:)

On 4/22/19 3:36 PM, Pedro Igor Silva wrote:
> transactional authorization could avoid. Both UMA and ACE have 
> solutions that make clients really dumb about what they need to send 
> to the AS in regards to scopes. IMO, the RS should have the 
> possibility to tell clients the scope they need, making a lot easier 
> to change RS's access constraints as well as pushing contextual 
> information that could eventually enrich the authorization process.
>
> On Mon, Apr 22, 2019 at 4:04 PM George Fletcher <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     ...it's possible in UMA 2 for the client to request additional
>     scopes when interacting with the token endpoint specifically to
>     address cases where the client knows it's going to make the
>     following requests and wants to obtain a token with sufficient
>     privilege for those requests. This requires a fair amount of
>     knowledge by the client of the ecosystem but that is sometimes the
>     case and hence this capability exists :)
>

---

From: Sascha Preibisch <[email-masked]>
Date: Tue, 23 Apr 2019 08:14:44 -0700

Hi Torsten!

If 'structured_scope' would become a generic field for application
specific content, I believe an indicator for the type of content would
be needed on the long run. That is what I meant my 'profile'. I hope
this helps!

Thank you,
Sascha

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 24 Apr 2019 19:08:25 +0200

Hi Sascha,

I see. I assume every element within the structured scope element to be an independent scope (value) object and intended to use the name of that object as kind of content type definition. 

In my last example, the scope is defined as 

   "structured_scope":{  
      "sign":{  
         "credentialID":"qes_eidas",
         "documentDigests":[  
            {  
               "hash":
                 "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
               "label":"Mobile Subscription Contract"
            }
         ],
         "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
      },
      "payment":{  
         "type":"sepa-credit-transfer",
         "instructedAmount":{  
            "currency":"EUR",
            "amount":"123.50"
         },
         "debtorAccount":{  
            "iban":"DE40100100103307118608"
         },
         "creditorName":"Merchant123",
         "creditorAccount":{  
            "iban":"DE02100100109307118603"
         },
         "remittanceInformationUnstructured":"new Smartphone"
      }

This means “sign" and “payment" would determine the scheme of the respective object. 

What do you think?

best regards, 
Torsten. 

> On 23. Apr 2019, at 17:14, Sascha Preibisch <[email-masked]> wrote:
> 
> Hi Torsten!
>

---

From: George Fletcher <[email-masked]>
Date: Thu, 25 Apr 2019 11:03:51 -0400

A couple of thoughts...

1. It doesn't feel like these are scopes (at least not as scope is 
defined by RFC 6749). It feels like they are more transaction requirements.

2. The schemas are going to be very ecosystem specific, correct?

On 4/24/19 1:08 PM, Torsten Lodderstedt wrote:
> This means ???sign" and ???payment" would determine the scheme of the respective object.
>
> What do you think?
>
> best regards,
> Torsten.
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 25 Apr 2019 19:54:47 +0200

> Am 25.04.2019 um 17:03 schrieb George Fletcher <[email-masked]>:
> 
> A couple of thoughts...
> 
> 1. It doesn't feel like these are scopes (at least not as scope is defined by RFC 6749). It feels like they are more transaction requirements.

What’s the difference? In my opinion, if you authorize a transaction it’s the same. Moreover, in other use cases (account information) it a complex requirement for a potentially long lasting grant.

In both cases, they describe the request power of the token == it’s scope.

> 2. The schemas are going to be very ecosystem specific, correct?

API (e.g. all psd2 standards), ecosystem, single deployment - just like „traditional“ scope values

---

From: Sascha Preibisch <[email-masked]>
Date: Thu, 25 Apr 2019 14:35:15 -0700

Torsten,

I think that works in most cases if you look at it that way.

It is just that elements such as 'iban' are practically unknown here
in Canada for example. This means, there needs to be a differentiator
that tells a client that one payment may be of type 'payment_eu' and
in the other case 'payment_ca'. Actually .... now I see the 'type'
element. With that, 'payment + type' would provide that information.

The only thing I would look into would be a change in the document
hierarchy to simply parsing of it. Potentially multiple payments could
be submitted at once also by adding a 'payments' root element:

{
"payment": {
"sepa-credit-transfer": {
"instructedAmount": {
"currency": "EUR",
"amount": "123.50"
},
"debtorAccount": {
"iban": "DE40100100103307118608"
},
"creditorName": "Merchant123",
"creditorAccount": {
"iban": "DE02100100109307118603"
},
"remittanceInformationUnstructured": "new Smartphone"
}
}
}

But generally, the 'structured_scope' is a good concept I think.

Thanks again, Torsten,

Sascha

---

From: Takahiko Kawasaki <[email-masked]>
Date: Fri, 26 Apr 2019 16:47:37 +0900

Dear Torsten,

I was impressed with your article. It describes considerations points very
well that implementers of leading-edge authorization servers will
eventually face or have already faced.

It seems to me that the mechanism of "structured_scope" can be positioned
as a more generic mechanism whose usage doesn't necessarily have to be
limited to scopes. I mean that the mechanism can be used to include any
arbitrary dynamic structured data in an authorization request. So, if there
were something I might be able to propose additionally, I would suggest
renaming "structured_scope" to a more generic name.

Best Regards,
Takahiko Kawasaki
Representative director, Authlete, Inc.

---

From: George Fletcher <[email-masked]>
Date: Fri, 26 Apr 2019 10:17:26 -0400

On 4/25/19 1:54 PM, Torsten Lodderstedt wrote:
>
>
> Am 25.04.2019 um 17:03 schrieb George Fletcher <[email-masked] 
> What???s the difference? In my opinion, if you authorize a transaction 
> it???s the same. Moreover, in other use cases (account information) it a 
> complex requirement for a potentially long lasting grant.
>
> In both cases, they describe the request power of the token == it???s scope.
I guess I look at scope as "authorized to transfer" maybe something like 
"authorized to transfer up to 10K". However the details of which account 
to take the money from and the account of where to put the money are not 
aspects of the scope but rather restrictions on the transaction.

It may be fine to have a model where the client tells the AS what 
transaction it wants to perform for the purpose of getting consent from 
the user to perform that transaction... but I don't think the details of 
the transaction should be considered scope(s).

For me.. scope is a capability the client is authorized to perform... 
"send an Instant message", or "read a buddy list".
> API (e.g. all psd2 standards), ecosystem, single deployment - just 
> like ???traditional??? scope values
Again, I would want the transaction requirements to be part of the API 
not part of the scope. In my mind, the authorization token should convey 
the client is authorized to perform a set of actions (capabilities) and 
then the API parameters define the exact details of that particular 
transaction.
>>>> On 23. Apr 2019, at 17:14, Sascha Preibisch<[email-masked]>  wrote:
>>>>
>>>> Hi Torsten!
>>>>
>>>>>> Am 22.04.2019 um 20:34 schrieb Sascha Preibisch<[email-masked]>:
>>>>>>
>>>>>>> I just published an article about the subject at:https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
>>>>>>>

---

From: George Fletcher <[email-masked]>
Date: Fri, 26 Apr 2019 10:35:11 -0400

Look at this in more detail... what about calling it 
"transactional_scope" instead of "structured_scope" as the scope is 
specific to an individual transaction and not applicable across 
transactions. That would then separate it from the more capability based 
'scope' provided by OAuth2.

In this context I like the pushed-request-object method as the resource 
server is going to need to pull the same transactional requirements when 
it receives the access token.

Thanks,
George

On 4/26/19 10:17 AM, George Fletcher wrote:
>> What???s the difference? In my opinion, if you authorize a 
>> transaction it???s the same. Moreover, in other use cases (account 
>> information) it a complex requirement for a potentially long lasting 
>> grant.
>>
> I guess I look at scope as "authorized to transfer" maybe something 
> like "authorized to transfer up to 10K". However the details of which 
> account to take the money from and the account of where to put the 
> money are not aspects of the scope but rather restrictions on the 
> transaction.
>
> transaction it wants to perform for the purpose of getting consent 
> from the user to perform that transaction... but I don't think the 
> details of the transaction should be considered scope(s).
>
> not part of the scope. In my mind, the authorization token should 
> convey the client is authorized to perform a set of actions 
> (capabilities) and then the API parameters define the exact details of 
> that particular transaction.
>>
>>>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 26 Apr 2019 11:57:14 -0600

One thing that I think is missing from the article in the discussion of
pros and cons is that in many cases a large or even voluminous request can
be sent via auto submitting form post (like
https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html but the
other way around from client to AS with the auth request), which doesn't
then run into the same URI size problem.

>From a prospective standardization standpoint, there are really two
distinct concepts in the article. One is the "Pushed Request Object" and
the other the "Structured Scope". They are certainly complementary things
but each could also be useful and used independently of one another. So I'd
argue that they should be developed independently too.

-- 
_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: Steinar Noem <[email-masked]>
Date: Fri, 26 Apr 2019 21:23:30 +0200

I do not have the depth of understanding of OAuth as you guys, so forgive
me if I'm missing the discussion completely.

For me this sort of boils down to how we establish trust between the
different roles in OAuth. For an API the trust lies between the AS and
itself. The API may have no trust in the clients directly, but relies on
the AS to provide the user consent, client authentication but also e.g. the
use of request objects. At least in my domain, the API might not trust
"claims" as parameters in a request from the client, but will trust the
"claims" in an access token.
In my domain the trust established between the client and the AS is an
important part of the ability to interact across security domains. It also
provides a way for us to establish domain standards for representing
different types of authoritative information.
For instance, we have a legal requirement to log certain types of
information about the user when exchanging sensitive information. This
information is usually tied to a OAuth scope, e.g. "get patient records".
The suggested use of "structured_scope" not only gives us an opportunity to
convey contextual information that can be shown in the user consent,  it
also gives us a way of enforcing national domain-specific standards of
expressing different types of information tied to the scope (e.g.
prescription, sick note, patient records etc) which would make
interoperability within the health sector easier.
Also, the health sector in Norway has a strict legislation regarding
privacy and patient rights,, so we would actually log the issued access
tokens with structured_scopes to fulfil some of the legal requirements.

Personally I'm not sure what makes more sense, the "structured_scope" or
"transaction_scope" name - but "transaction_scope" is more semantically
loaded.
I also agree with mr. Campbell that the concepts should be treated
separately.

<mvh>Steinar</mvh>

fre. 26. apr. 2019 kl. 19:58 skrev Brian Campbell <bcampbell=
[email-masked]>:

> https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html but
> the other way around from client to AS with the auth request), which
> doesn't then run into the same URI size problem.
>
> *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.*_______________________________________________
> OAuth mailing list
> [email-masked]

-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 27 Apr 2019 23:08:21 -0500

> This means “sign" and “payment" would determine the scheme of the respective object. 

I think it reminds me of why draft-ietf-oauth-jwt-bcp recommends using the
"typ" header, and all the reasoning we have to do about different types of
tokens (not) being replayable at a different endpoint and being interpreted
wrongly.

-Ben

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 30 Apr 2019 12:08:32 +0200

> Am 28.04.2019 um 06:08 schrieb Benjamin Kaduk <[email-masked]>:
> 

While I agree with the need to use the typ header, I don’t see a direct relationship to my proposal as it is about specifying the intended scope of tokens but not the token format itself. Can you explain your thoughts in more detail?

kind regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 30 Apr 2019 12:24:50 +0200

Dear Taka,

thanks for your feedback.

How would this more generic mechanism differ from the JSON-based request object? I personally would advocate to use both, structured scope & pushed request object, to together.

best regards,
Torsten.

> Am 26.04.2019 um 09:47 schrieb Takahiko Kawasaki <[email-masked]>:
> 
> Dear Torsten,
> 
> I was impressed with your article. It describes considerations points very well that implementers of leading-edge authorization servers will eventually face or have already faced.
> 
> It seems to me that the mechanism of "structured_scope" can be positioned as a more generic mechanism whose usage doesn't necessarily have to be limited to scopes. I mean that the mechanism can be used to include any arbitrary dynamic structured data in an authorization request. So, if there were something I might be able to propose additionally, I would suggest renaming "structured_scope" to a more generic name.
> 
> Best Regards,
> Takahiko Kawasaki

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 30 Apr 2019 12:26:48 +0200

Sascha,

I see the challenge, thanks!

Potentially, one would need to have a more explicit typing support (schemes?) and use the name of the individual elements just as names, e.g. payment1, payment2.

best regards,
Torsten.

> Am 25.04.2019 um 23:35 schrieb Sascha Preibisch <[email-masked]>:
> 
> Torsten,
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 30 Apr 2019 12:39:48 +0200

> Am 26.04.2019 um 16:17 schrieb George Fletcher <[email-masked]>:
> 
> 
> 
>> What???s the difference? In my opinion, if you authorize a transaction it???s the same. Moreover, in other use cases (account information) it a complex requirement for a potentially long lasting grant.
>> 
> I guess I look at scope as "authorized to transfer" maybe something like "authorized to transfer up to 10K". However the details of which account to take the money from and the account of where to put the money are not aspects of the scope but rather restrictions on the transaction. 
> 
> It may be fine to have a model where the client tells the AS what transaction it wants to perform for the purpose of getting consent from the user to perform that transaction... but I don't think the details of the transaction should be considered scope(s).
> 
> For me.. scope is a capability the client is authorized to perform... "send an Instant message", or "read a buddy list".
>> 
>>> 
>> API (e.g. all psd2 standards), ecosystem, single deployment - just like ???traditional??? scope values
> Again, I would want the transaction requirements to be part of the API not part of the scope. In my mind, the authorization token should convey the client is authorized to perform a set of actions (capabilities) and then the API parameters define the exact details of that particular transaction.

I understand your sentiments. How would you envision to ask a user for consent about those details if this consent is required by law?

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 30 Apr 2019 13:01:10 +0200

> On 26. Apr 2019, at 16:35, George Fletcher <[email-masked]> wrote:
> 
> Look at this in more detail... what about calling it "transactional_scope" instead of "structured_scope" as the scope is specific to an individual transaction and not applicable across transactions. That would then separate it from the more capability based 'scope' provided by OAuth2.

There are cases, where the scope/token is applicable across multiple requests for a longer period. A request for access to account information service, for example, would look like this:

{  
   "access":{  
      "balances":[  
         {  
            "iban":"DE40100100103307118608"
         },
         {  
            "iban":"DE02100100109307118603"
         }
      ],
      "transactions":[  
         {  
            "iban":"DE40100100103307118608"
         }
      ]
   },
   "recurringIndicator":true,
   "validUntil":"2017-11-01",
   "frequencyPerDay":"4"
}

> 
> In this context I like the pushed-request-object method as the resource server is going to need to pull the same transactional requirements when it receives the access token.

All in one place :-)

best,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 30 Apr 2019 13:03:19 +0200

> On 26. Apr 2019, at 19:57, Brian Campbell <[email-masked]> wrote:
> 
> One thing that I think is missing from the article in the discussion of pros and cons is that in many cases a large or even voluminous request can be sent via auto submitting form post (like https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html but the other way around from client to AS with the auth request), which doesn't then run into the same URI size problem. 

Thanks for pointing this out! Is the response mode often used in the wild for OAuth?

> 
> From a prospective standardization standpoint, there are really two distinct concepts in the article. One is the "Pushed Request Object" and the other the "Structured Scope". They are certainly complementary things but each could also be useful and used independently of one another. So I'd argue that they should be developed independently too.

I agree. I’m considering two separate drafts.

> 
> 
> 
> On Sat, Apr 20, 2019 at 12:21 PM Torsten Lodderstedt <[email-masked]> wrote:
> Hi all, 
> 
> 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: Tue, 30 Apr 2019 10:55:35 -0600

> Thanks for pointing this out! Is the response mode often used in the wild

It's not really a "response mode" for sending the request but the idea is
basically the same just going the other direction. The possibility is
implied by the text near the end of
https://tools.ietf.org/html/rfc6749?#section-3.1 that says,

  'The authorization server MUST support the use of the HTTP "GET"
   method [RFC2616] for the authorization endpoint and MAY support the
   use of the "POST" method as well.'

I know our AS will happily accept POST at the authorization endpoint and I
suspect many others will too. But I don't have any data how often it is
used in the wild for OAuth.