Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth (Torsten Lodderstedt)

From: Jaap Francke <[email-masked]>
Date: Thu, 25 Apr 2019 07:27:05 +0000

Hi Torsten and others,

I just read your blog - having “we need to re-think OAuth scopes” in the title immediately drew my attention.
I find this interesting since I’m struggling with the concept of scopes from time-to-time.
I’ll have to read the blog a few times more to get a good understanding, but I would like to share some of my thoughts on scopes.

I believe the OAuth scope concept has it’s limitations not only for transactions but also for the more traditional ‘resource’ concept.
RFC 6749 defines scopes as follows:
"The value of the scope parameter is expressed as a list of space-
   delimited, case-sensitive strings.  The strings are defined by the
   authorization server.  If the value contains multiple space-delimited
   strings, their order does not matter, and each string adds an
   additional access range to the requested scope.”

I see 2 aspects in this definition:
- how the strings should look like is beyond the scope of the RFC
- each string adds an additional authorisation

Scopes are associated with access_tokens, which typically are bearer tokens as defined by RFC 6750 as:
      A security token with the property that any party in possession of
      the token (a "bearer") can use the token in any way that any other
      party in possession of it can.  Using a bearer token does not
      require a bearer to prove possession of cryptographic key material
      (proof-of-possession).”

This implies that every scope value should fully describe the authorisation that is given. In my view that is rarely done, which is the main reason why I find myself struggling with scope-concept.

Here we have a collection of examples, which demonstrate to me that everyone is inventing their own wheels according to their specfic needs:
https://brandur.org/oauth-scope
https://api.slack.com/docs/oauth-scopes

In various other (draft) standards I see bits and pieces that seem to address this issue.

In UMA an authorisation is conceptually broken down into:
- subject -> requesting party
- verbs -> scopes of access
- object -> resource set.
I like this line of thinking and terminilogy.  However, if access_tokens are bearer tokens, I think ’subject’ is the bearer of the token.

The most common practice, I think, is to use OIDC’s IDTokens to contain a set of claims that scope the scope of the scope :-).

I mean that the claims in the ID-Tokens are used to scope the objects as well as the verbs/scopes of access.

The core intention behind ID-token is to provide information about the authenticated user and not necessarily about the resources that are accessed. In practice, claims about the authenticated users indicate which resources (photos) can be accessed at the resource server.

My understanding of this draft https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02

is that the object/resource aspect of authorisation is taken somewhat out of the scope and put into a dedicated parameter. Although (using the example from RFC 6749) the resource parameter indicates the resource server (or application,

   API, etc.) rather than an individual resource that is stored at the resource server. So additional scoping of object/resource set is still needed in addition to the resource parameter.

Furthermore, https://tools.ietf.org/html/draft-ietf-oauth-security-topics-12 makes some interesting statements that are relevant in my view:
The section on Access Token privilege restriction says "access tokens SHOULD be restricted to certain resources

   and actions on resource servers or resources.” So the OAuth scope-string still needs to somehow indicate the resource-scope of the privilege that is communicated.

" The client needs to tell the authorization server, at which URL it

   will use the access token it is requesting.  It could use the
   mechanism proposed [I-D.ietf-oauth-resource-indicators<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-12#ref-I-D.ietf-oauth-resource-indicators>] or encode the
   information in the scope value.”

I’m not sure which point I’m trying to make; i guess the need for standardisation how to use and define OAuth-scopes.

I like the Lodging Intent Pattern and need to do some more reading/thinking about the structured-scope and pushed request objects.

I feel these concepts are not only relevant for authorisation of transactions, but also for any access that needs authorisation.

I’m not sure if i express myself clearly, nevertheless any feedback is welcome, if not alone to get my understanding of the various concepts on a higher level.

Thanks in advance, kind regards

Jaap

Message: 1
Date: Wed, 24 Apr 2019 19:08:25 +0200
From: Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>>
To: Sascha Preibisch <[email-masked]<mailto:[email-masked]>>
Cc: oauth <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
Message-ID: <[email-masked]<mailto:[email-masked]>>
Content-Type: text/plain; charset=utf-8

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]<mailto:[email-masked]>> wrote:

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

Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
<[email-masked]<mailto:[email-masked]>>:

Hi Sascha,

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

Thank you for the article, Torsten!

my pleasure :-)

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.

What does profile mean in this context?

best regards,
Torsten.

Thank you,
Sascha

Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
<[email-masked]<mailto:[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

I look forward to getting your feedback.

kind regards,
Torsten.
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

------------------------------

Subject: Digest Footer

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

------------------------------

End of OAuth Digest, Vol 126, Issue 58
**************************************

---

From: Pedro Igor Silva <[email-masked]>
Date: Fri, 26 Apr 2019 11:06:33 -0300

Hi Jaap,

Very good points. I have the same opinion about what you said about the
meaning of scopes (and how people are actually using them), the
resource-scope relationship and the importance of a standardized way of
doing this form of authorization to address different use cases, not only
delegation. Like George said in one of his messages, both 1st and 3rd party
use cases could be considered by a solution like that.

I would love to see something based on OAuth like this:

#1) Client tries to access a protected resource. At this point, the client
does not yet have a bearer token or the bearer token is lacking the
required scopes/permissions. The resource server responds with:

*HTTP/1.1 403 Unauthorized *
*WWW-Authenticate: Bearer realm="example",
error="invalid_token",
claim_token="accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC"*

The claim_token response parameter returned by the resource server
represents all the security constraints (e.g.: scopes) and information
(e.g.: contextual) that the client needs in order to obtain a valid access
token from the AS. This token can be built by the RS or even use some
endpoint at the AS, as UMA does. It can be just a reference token too.

#2) Client obtains an access token from the token endpoint at the AS:

*POST /as/token.oauth2 HTTP/1.1*
*Host: as.example.com <http://as.example.com/>*
*Content-Type: application/x-www-form-urlencoded*
*grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Apermission*
*&resource=https%3A%2F%2Fbackend.example.com
<http://2fbackend.example.com/>%2Fapi%20*
*&claim_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC*
*&subject_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC*
*&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token*

The example above shows a client request to the token endpoint when the
client already has an access token and wants a new token with permissions
to access a resource.

#3) Just like any other OAuth grant type, the token endpoint responds to
the client as follows (success):

*HTTP/1.1 200 OK*
*Content-Type: application/json;charset=UTF-8*
*Cache-Control: no-store*
*Pragma: no-cache*

*{*
*"access_token":"2YotnFZFEjr1zCsicMWpAA"*
*"token_type":"example",*
*"expires_in":3600,*
*"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"*
*} *

#4) Clients can now access protected resources using the access token with
all permissions granted by the server

It is not coincidence the similarities with and the usage of specs/drafts
like token exchange, resource-indicator, UMA, Lodging Intent Pattern, or
even ACE's "AS Request Creation Hints" message. The point I would like to
make is that we could leverage the standards/specs that exist today to
address the problem without reinventing the wheel.

There are very interesting things in UMA specs that can be used here too,
such as the possibility to perform incremental authorization or token
upgrade, etc.

Regards.
Pedro Igor

On Thu, Apr 25, 2019 at 4:27 AM Jaap Francke <jaap.francke=
[email-masked]> wrote:

> I’ll have to read the blog a few times more to get a good understanding,
> but I would like to share some of my thoughts on scopes.
>
> I believe the OAuth scope concept has it’s limitations not only for
> transactions but also for the more traditional ‘resource’ concept.
> This implies that every scope value should fully describe the
> authorisation that is given. In my view that is rarely done, which is the
> main reason why I find myself struggling with scope-concept.
>
> Here we have a collection of examples, which demonstrate to me that
> everyone is inventing their own wheels according to their specfic needs:
> I like this line of thinking and terminilogy.  However, if access_tokens
> are bearer tokens, I think ’subject’ is the bearer of the token.
>
> Furthermore,
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-12 makes
> some interesting statements that are relevant in my view:
> The section on Access Token privilege restriction says "access tokens
> SHOULD be restricted to certain resources
>
>    mechanism proposed [I-D.ietf-oauth-resource-indicators <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-12#ref-I-D.ietf-oauth-resource-indicators>] or encode the
> From: Torsten Lodderstedt <[email-masked]>
> To: Sascha Preibisch <[email-masked]>
> Cc: oauth <[email-masked]>
> Message-ID: <[email-masked]>
> 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.
>
> On 23. Apr 2019, at 17:14, Sascha Preibisch <[email-masked]>
> wrote:
>
> Hi Torsten!
>
> <[email-masked]>:
>
>
> Hi Sascha,
>
> Am 22.04.2019 um 20:34 schrieb Sascha Preibisch <[email-masked]
> >:
>
> <[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
>
> [email-masked]
> [email-masked]
> [email-masked]

---

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

I agree that we definitely need better definition and guidance around 
scopes and authorized access patterns.

I think what is unique about what Torsten is proposing is that in his 
case he wants to authorize an individual transaction (not a set of 
transactions). Normally, with scopes and access tokens the goal is to 
get an access token that can perform a number of transactions with a 
restricted set of capabilities.

I think we need to separate the concept of transactional authorization 
from capability authorization.

On 4/26/19 10:06 AM, Pedro Igor Silva wrote:
> Hi Jaap,
>
> Very good points. I have the same opinion about what you said about 
> the meaning of scopes (and how people are actually using them), the 
> resource-scope relationship and the importance of a standardized way 
> of doing this form of authorization to address different use cases, 
> not only delegation. Like George said in one of his messages, both 1st 
> and 3rd party use cases could be considered by a solution like that.
>
> #1) Client tries to access a protected resource. At this point, the 
> client does not yet have a bearer token or the bearer token is lacking 
> the required scopes/permissions. The resource server responds with:
>
> /HTTP/1.1 403 Unauthorized /
> /WWW-Authenticate: Bearer realm="example", error="invalid_token", 
> *claim_token*="accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC"/
>
> (e.g.: contextual) that the client needs in order to obtain a valid 
> access token from the AS. This token can be built by the RS or even 
> use some endpoint at the AS, as UMA does. It can be just a reference 
> token too.
>
> /POST /as/token.oauth2 HTTP/1.1/
> /Host: as.example.com <http://as.example.com/>/
> /Content-Type: application/x-www-form-urlencoded/
> /grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Apermission/
> /&resource=https%3A%2F%2Fbackend.example.com 
> <http://2fbackend.example.com/>%2Fapi%20/
> /&*claim_token*=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC/
> /&subject_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC/
> /&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token/
>
> The example above shows a client request to the token endpoint when 
> the client already has an access token and wants a new token with 
> permissions to access a resource.
>
> #3) Just like any other OAuth grant type, the token endpoint responds 
> to the client as follows (success):
>
> /HTTP/1.1 200 OK/
> /Content-Type: application/json;charset=UTF-8/
> /Cache-Control: no-store/
> /Pragma: no-cache/
> /
> /
> /{/
> /"access_token":"2YotnFZFEjr1zCsicMWpAA"/
> /"token_type":"example",/
> /"expires_in":3600,/
> /"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"/
> /} /
> /
> /
> #4) Clients can now access protected resources using the access token 
> with all permissions granted by the server
>
> It is not coincidence the similarities with and the usage of 
> specs/drafts like token exchange, resource-indicator, UMA, Lodging 
> Intent Pattern,??or even ACE's "AS Request Creation Hints" message. The 
> point I would like to make is that we could leverage the 
> standards/specs that exist today to address the problem without 
> reinventing the wheel.
>
> There are very interesting things in UMA specs that can be used here 
> too, such as the possibility to perform incremental authorization or 
> token upgrade, etc.
>
> Regards.
> Pedro Igor
>
> On Thu, Apr 25, 2019 at 4:27 AM Jaap Francke 
> <jaap.francke=[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Torsten and others,
>
>     I just read your blog - having ???we need to re-think OAuth scopes???
>     in the title immediately drew my attention.
>     I find this interesting since I???m struggling with the concept of
>     scopes from time-to-time.
>     I???ll have to read the blog a few times more to get a good
>     understanding, but I would like to share some of my thoughts on
>     scopes.
>
>     I believe the OAuth scope concept has it???s limitations not only
>     for transactions but also for the more traditional ???resource??? concept.
>     ???? delimited, case-sensitive strings.?? The strings are defined by the
>     ???? authorization server.?? If the value contains multiple
>     space-delimited
>     ???? strings, their order does not matter, and each string adds an
>     ???? additional access range to the requested scope.???
>
>     ?????????? A security token with the property that any party in
>     possession of
>     ?????????? the token (a "bearer") can use the token in any way that any
>     other
>     ?????????? party in possession of it can.?? Using a bearer token does not
>     ?????????? require a bearer to prove possession of cryptographic key
>     material
>     (proof-of-possession).???
>
>     authorisation that is given. In my view that is rarely done, which
>     is the main reason why I find myself struggling with scope-concept.
>
>     Here we have a collection of examples, which demonstrate to me
>     that everyone is inventing their own wheels according to their
>     specfic needs:
>     I like this line of thinking and terminilogy. However, if
>     access_tokens are bearer tokens, I think ???subject??? is the bearer
>     of the token.
>
>     The most common practice, I think, is to use OIDC???s IDTokens to
>     contain a set of claims that scope the scope of the scope :-).
>
>     I mean that the claims in the ID-Tokens are used to scope the
>     objects as well as the verbs/scopes of access.
>
>     The core intention behind ID-token is to provide information about
>     the authenticated user and not necessarily about the resources
>     that are accessed. In practice, claims about the authenticated
>     users indicate which resources (photos) can be accessed at the
>     resource server.
>
>     My understanding of this draft
>     https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02
>
>     is that the object/resource aspect of authorisation is taken
>     somewhat out of the scope and put into a dedicated parameter.
>     Although (using the example from RFC 6749) the resource parameter
>     indicates theresource server (or application,
>
>     API, etc.) rather than an individual resource that is stored at
>     the resource server. So additional scoping of object/resource set
>     is still needed in addition to the resource parameter.
>
>
>
>     Furthermore,
>     https://tools.ietf.org/html/draft-ietf-oauth-security-topics-12??makes
>     The section on Access Token privilege restriction says "access
>     tokens SHOULD be restricted to certain resources
>
>     and actions on resource servers or resources.??? So the OAuth
>     scope-string still needs to somehow indicate the resource-scope of
>     the privilege that is communicated.
>
>     "The client needs to tell the authorization server, at which URL it
>
>         information in the scope value.???
>
>     I???m not sure which point I???m trying to make; i guess the need for
>     standardisation how to use and define OAuth-scopes.
>
>     I like the Lodging Intent Pattern and need to do some more
>     reading/thinking about the structured-scope and pushed request
>     objects.
>
>     I feel these concepts are not only relevant for authorisation of
>     transactions, but also for any access that needs authorisation.
>
>     I???m not sure if i express myself clearly, nevertheless any
>     feedback is welcome, if not alone to get my understanding of the
>     various concepts on a higher level.
>
>>     Cc: oauth <[email-masked] <mailto:[email-masked]>>
>>     Message-ID: <[email-masked]
>>     <mailto:[email-masked]>>
>>     Content-Type: text/plain;charset=utf-8
>>
>>     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.
>>
>>     ????"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"
>>     ??????????}
>>
>>>     On 23. Apr 2019, at 17:14, Sascha Preibisch
>>>     <[email-masked] <mailto:[email-masked]>>
>>>     wrote:
>>>
>>>     Hi Torsten!
>>>
>>>     <[email-masked] <mailto:[email-masked]>>:
>>>>
>>>>     Hi Sascha,
>>>>
>>>>>     Am 22.04.2019 um 20:34 schrieb Sascha Preibisch
>>>>>     <[email-masked] <mailto:[email-masked]>>:
>>>>>
>>>>>     <[email-masked] <mailto:[email-masked]>>:
>>>>>>
>>>>>>     Hi all,
>>>>>>
>>>>>>     <https://medium..com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948>
>>>>>>
>>>>>>     [email-masked] <mailto:[email-masked]>
>>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

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

Hi Jaap,

thanks for sharing your thoughts with us.

> On 25. Apr 2019, at 09:27, Jaap Francke <jaap.francke=[email-masked]> wrote:
> 
> Hi Torsten and others,
> 
> This implies that every scope value should fully describe the authorisation that is given.

I couldn’t agree more :-) 

One subtle difference: I would state the "authorization asked for”. Why this differentiation? In the implementations I was responsible for in the past (consumer facing services), the scope value always indicated the service the client wanted to access BUT the access tokens typically carried the user id and user claims needed to authorize the call (on behalf of the resource owner) with the RS. Scope values or parts of it could have been added to the tokens as well. But the point want to get across is, the scope pass into an authorization transaction might get transformed in some other data in the token.

> In my view that is rarely done, which is the main reason why I find myself struggling with scope-concept.

The scope parameter was kept very generic and simple in RFC 6749 in order to not limit implementors and keep implementation complexity low. The concept was ok at that time (2012!) but is longer suitable for current use cases and the fact clients want to access more than a single service using a certain grant. 

> I like this line of thinking and terminilogy.  However, if access_tokens are bearer tokens, I think ’subject’ is the bearer of the token.

I would argue the bearer is acting on behalf of the subject. Even in case of sender-constraint tokens (or PoP tokens), it’s not necessarily the user (resource owner) interacting with the service. The proof material just confirms that the legit client uses the token. 

> The most common practice, I think, is to use OIDC’s IDTokens to contain a set of claims that scope the scope of the scope :-). 

Never seen that. Can you share examples?

>    API, etc.) rather than an individual resource that is stored at the resource server. So additional scoping of object/resource set is still needed in addition to the resource parameter.

Resource indicators is an incremental extension to OAuth allowing issuance of RS-specific access tokens based on the same grant (audience restriction and so on). It was possible before, e.g. by using scope values to represent RSs, but there was no standardised way to indicate the intended RS to the AS. I learned this made it difficult for OAuth products to support per RS access tokens based on the same grant. 

>    and actions on resource servers or resources.” So the OAuth scope-string still needs to somehow indicate the resource-scope of the privilege that is communicated.

Well, there needs to be a way to indicate the RS (or resource) the client wants to interact with. Resource indicators is one way. I definitely envision to have this feature in structured scopes. Resource indicators is a bit limited since resource URI and requested permissions (scope) are kept separate. But “read” might have a different meaning at different resources.  

That’s why the structured scope will allow the client to indicate the resource along with the requested permission on that particular resource.

Here is an example:
{  
   "structured_scope":{  
      "email":{  
         "server":"imap.example.com",
         "actions":[  
            "read"
         ]
      },
      "cloud":{  
         "server":"https://webdav.example.com",
         "actions":[  
            "read",
            "write"
         ]
      }
   }
}

>    mechanism proposed [
> I-D.ietf-oauth-resource-indicators
> ] or encode the

I agree again :-) A structured scope draft should definitely not limit the mechanism to transaction authorization. 

> I’m not sure if i express myself clearly, nevertheless any feedback is welcome, if not alone to get my understanding of the various concepts on a higher level.

Thanks a lot for your feedback. It was very helpful to direct further work. I hope you will stay involved!

best regards,
Torsten. 

>>> 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]>:
>>>>>