subject:"Re\: \[OAUTH\-WG\] Transaction Authorization with OAuth"

 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. 

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

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"
 ]
  }
   }
}



> 
> " 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 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. 

> 
> Thanks in advance, kind regards
> 
> Jaap
> 
> 
> 
> 
> 
> 
> 
>> Message: 1
>> Date: Wed, 24 Apr 2019 19:08:25 +0200
>> From: Torsten Lodderstedt 
>> To: Sascha Preibisch 
>> Cc: oauth 
>> Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
>> Message-ID: <2997b550-c82b-4d3a-9639-15a004f2f...@lodderstedt.net>
>> 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":"DE0210

Re: [OAUTH-WG] Transaction Authorization with OAuth



> On 26. Apr 2019, at 19:57, Brian Campbell  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 
>  wrote:
> 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
> 
> 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Transaction Authorization with OAuth




> On 26. Apr 2019, at 16:35, George Fletcher  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. 

> 
> Thanks,
> George
> 
> On 4/26/19 10:17 AM, George Fletcher wrote:
>> 
>> 
>> On 4/25/19 1:54 PM, Torsten Lodderstedt wrote:
>>> 
>>> 
>>> 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.
>> 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".
>>> 
 
 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
>> 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 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

Re: [OAUTH-WG] Transaction Authorization with OAuth



> Am 26.04.2019 um 16:17 schrieb George Fletcher :
> 
> 
> 
>> On 4/25/19 1:54 PM, Torsten Lodderstedt wrote:
>> 
>> 
>> 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.
> 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".
>> 
>>> 
>>> 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
> 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?

>> 
>>> 
 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.
 ___
>>

Re: [OAUTH-WG] Transaction Authorization with OAuth

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


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

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 :
> 
> 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.
> 
> 2019年4月21日(日) 3:21 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


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



> Am 28.04.2019 um 06:08 schrieb Benjamin Kaduk :
> 
>> On Wed, Apr 24, 2019 at 07:08:25PM +0200, 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?
> 
> 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.

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.

> 
> -Ben


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

2019-04-27 Thread Benjamin Kaduk

On Wed, Apr 24, 2019 at 07:08:25PM +0200, 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?

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

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

Re: [OAUTH-WG] Transaction Authorization with OAuth

2019-04-26 Thread Steinar Noem

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.

Steinar

fre. 26. apr. 2019 kl. 19:58 skrev Brian Campbell :

> 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.
>
>
>
> On Sat, Apr 20, 2019 at 12:21 PM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> 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
>>
>
> *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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| stei...@udelt.no | h...@udelt.no  | +47 955 21 620 | www.udelt.no |
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Transaction Authorization with OAuth

2019-04-26 Thread Brian Campbell

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.



On Sat, Apr 20, 2019 at 12:21 PM Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

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

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

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

2019-04-26 Thread George Fletcher

fined 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 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
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 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: <2997b550-c82b-4d3a-9639-15a004f2f...@lodderstedt.net
<mailto:2997b550-c82b-4d3a-9639-15a004f2f...@lodderstedt.net>>
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+474gFj0q0x1iSNspKqbcse4IeiqlD

Re: [OAUTH-WG] Transaction Authorization with OAuth

2019-04-26 Thread George Fletcher

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:

On 4/25/19 1:54 PM, Torsten Lodderstedt wrote:

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.
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".

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

Re: [OAUTH-WG] Transaction Authorization with OAuth

2019-04-26 Thread George Fletcher

On 4/25/19 1:54 PM, Torsten Lodderstedt wrote:

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.
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".

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

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!

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)

2019-04-26 Thread Pedro Igor Silva

at
> 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 
> To: Sascha Preibisch 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
> Message-ID: <2997b550-c82b-4d3a-9639-15a004f2f...@lodderstedt.net>
> 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":{
>&q

Re: [OAUTH-WG] Transaction Authorization with OAuth

2019-04-26 Thread Takahiko Kawasaki

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.

2019年4月21日(日) 3:21 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

2019-04-25 Thread 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

2019-04-25 Thread 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

2019-04-25 Thread 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)

2019-04-25 Thread 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<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 
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: 
<2997b550-c82b-4d3

Re: [OAUTH-WG] Transaction Authorization with OAuth

2019-04-24 Thread 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

2019-04-23 Thread Sascha Preibisch

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

2019-04-23 Thread George Fletcher

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


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

On 4/22/19 1:18 PM, Torsten Lodderstedt wrote:

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.




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

Re: [OAUTH-WG] Transaction Authorization with OAuth

2019-04-23 Thread George Fletcher


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#seek-authorization

On 4/23/19 1:04 AM, Torsten Lodderstedt wrote:

Does UMA use the standard scope parameter?

Am 22.04.2019 um 21:03 schrieb George Fletcher >:



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


On 4/22/19 1:18 PM, Torsten Lodderstedt wrote:

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.




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

Re: [OAUTH-WG] Transaction Authorization with OAuth

2019-04-23 Thread Steinar Noem

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 <
tors...@lodderstedt.net>:

> HI Steinar,
>
> > On 22. Apr 2019, at 10:38, Steinar Noem  wrote:
> >
> > Hi Torsten, thank you for writing this clarifying article :)
>
> 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/”,
>
> 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 <
> tors...@lodderstedt.net>:
> > 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
> > --
> > Vennlig hilsen
> >
> > Steinar Noem
> > Partner Udelt AS
> > Systemutvikler
> >
> > | stei...@udelt.no | h...@udelt.no  | +47 955 21 620 | www.udelt.no |
>
>

-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| stei...@udelt.no | h...@udelt.no  | +47 955 21 620 | www.udelt.no |
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Transaction Authorization with OAuth

Thanks for sharing this recommendation!

> Am 21.04.2019 um 22:41 schrieb Vladimir Dzhuvinov :
> 
> 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
> 
>> On 20/04/2019 21:21, Torsten Lodderstedt wrote:
>> 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


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

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


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

Does UMA use the standard scope parameter?

> Am 22.04.2019 um 21:03 schrieb George Fletcher :
> 
> 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 :)
> 
>> On 4/22/19 1:18 PM, Torsten Lodderstedt wrote:
>> 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. 
> 


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

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

> 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 :)
>
> On 4/22/19 1:18 PM, Torsten Lodderstedt wrote:
>
> 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.
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Transaction Authorization with OAuth

2019-04-22 Thread George Fletcher


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


On 4/22/19 1:18 PM, Torsten Lodderstedt wrote:

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.


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

Re: [OAUTH-WG] Transaction Authorization with OAuth

2019-04-22 Thread Sascha Preibisch

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

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



> Am 22.04.2019 um 19:54 schrieb Pedro Igor Silva :
> 
> 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:51 PM Pedro Igor Silva  wrote:
>> 
>> 
>>> On Mon, Apr 22, 2019 at 2:18 PM Torsten Lodderstedt 
>>>  wrote:
>>> Hi Pedro,
>>> 
>>> > 
>>> > > 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). 
>>> > 
>>> > 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.
>>> 
>>> 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.
>>> 
>>> 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. 
>>> 
>>> >  
>>> > 
>>> > > 
>>> > > 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.
>>> > 
>>> > > Best regards.
>>> > > Pedro Igor
>>> > > 
>>> > > On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt 
>>> > >  wrote:
>>> > > 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
>>> > 
>>> 


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

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

>
>
> On Mon, Apr 22, 2019 at 2:18 PM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> Hi Pedro,
>>
>> >
>> > > 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)..
>> >
>> > 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.
>>
>> 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.
>>
>> 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.
>>
>> >
>> >
>> > >
>> > > 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.
>> >
>> > > Best regards.
>> > > Pedro Igor
>> > >
>> > > On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt <
>> tors...@lodderstedt.net> wrote:
>> > > 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

On Mon, Apr 22, 2019 at 2:18 PM Torsten Lodderstedt 
wrote:

> Hi Pedro,
>
> >
> > > 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).
> >
> > 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.
>
> 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.
>
> 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.
>
> >
> >
> > >
> > > 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.
> >
> > > Best regards.
> > > Pedro Igor
> > >
> > > On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
> > > 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

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  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 Apr 22, 2019, at 9:34 AM, Pedro Igor Silva  wrote:
> 
>> 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
>> 
>> On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt 
>>  wrote:
>> 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

Hi Pedro,

> 
> > 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). 
> 
> 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.

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. 

>  
> 
> > 
> > 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.
> 
> > Best regards.
> > Pedro Igor
> > 
> > On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt 
> >  wrote:
> > 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

On Mon, Apr 22, 2019 at 1:33 PM Torsten Lodderstedt 
wrote:

> Hi Pedro,
>
> > On 22. Apr 2019, at 16:34, Pedro Igor Silva  wrote:
> >
> > Hi Torsten,
> >
> > Great article, thanks for sharing it.
>
> my pleasure :-)
>
> >
> > 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).
>
> 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.


>
> >
> > 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.
>
> > Best regards.
> > Pedro Igor
> >
> > On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
> > 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

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  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 Apr 22, 2019, at 9:34 AM, Pedro Igor Silva  wrote:
>
> 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
>
> On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt <
> tors...@lodderstedt.net > wrote:
>
>> 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

Hi Pedro,

> On 22. Apr 2019, at 16:34, Pedro Igor Silva  wrote:
> 
> Hi Torsten,
> 
> Great article, thanks for sharing it.

my pleasure :-)

> 
> 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). 

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.

> Best regards.
> Pedro Igor
> 
> On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt  
> wrote:
> 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

HI Steinar,

> On 22. Apr 2019, at 10:38, Steinar Noem  wrote:
> 
> Hi Torsten, thank you for writing this clarifying article :)

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/”,

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 
> :
> 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
> -- 
> Vennlig hilsen
> 
> Steinar Noem
> Partner Udelt AS
> Systemutvikler
>  
> | stei...@udelt.no | h...@udelt.no  | +47 955 21 620 | www.udelt.no | 

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

Re: [OAUTH-WG] Transaction Authorization with OAuth

2019-04-22 Thread Jim Manico

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  wrote:
> 
> 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
> 
>> On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt 
>>  wrote:
>> 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