Re: [OAUTH-WG] Transaction Authorization with OAuth

[Sascha Preibisch]

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

Am Mi., 24. Apr. 2019 um 10:08 Uhr schrieb Torsten Lodderstedt
:
>
> 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  
> > 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
> > :
> >>
> >> Hi Sascha,
> >>
> >>> Am 22.04.2019 um 20:34 schrieb Sascha Preibisch 
> >>> :
> >>>
> >>> 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
> >>> :
> 
>  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
>  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] Transaction Authorization with OAuth

[Torsten Lodderstedt]

> Am 25.04.2019 um 17:03 schrieb George Fletcher :
> 
> 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

> 
>> On 4/24/19 1:08 PM, Torsten Lodderstedt wrote:
>> 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  
 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
 :
 Hi Sascha,
 
>> Am 22.04.2019 um 20:34 schrieb Sascha Preibisch 
>> :
>> 
>> 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
> :
>> 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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 


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

Re: [OAUTH-WG] Transaction Authorization with OAuth

[George Fletcher]

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:

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

Hi Sascha,


Am 22.04.2019 um 20:34 schrieb Sascha Preibisch :

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
:

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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
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] Transaction Authorization with OAuth (Torsten Lodderstedt)

[Jaap Francke]

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]
 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 
mailto:tors...@lodderstedt.net>>
To: Sascha Preibisch 
mailto:saschapreibi...@gmail.com>>
Cc: oauth mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
Message-ID: