[OAUTH-WG] Dynamic Scopes

[Torsten Lodderstedt]

Hi all,

I have been working lately on use cases where OAuth is used to authorize 
transactions in the financial sector and electronic signing. What I learned is 
there is always the need to pass resource ids (e.g. account numbers) or 
transaction-specific values (e.g. amount or hash to be signed) to the OAuth 
authorization process to further qualify the scope of the requested access 
token. 

It is obvious a static scope value, such as „payment“or „sign“, won’t do the 
job. For example in case of electronic signing, one must bind the 
authorization/access token to a particular document, typically represented by 
its hash.

I would like to get your feedback on what you consider a good practice to cope 
with that challenge. As a starting point for a discussion, I have assembled a 
list of patterns I have seen in the wild (feel free to extend). 

(1) Parameter is part of the scope value, e.g. „sign:“ or 
"payments:" - I think this is an obvious way to represent 
such parameters in OAuth, as it extends the scope parameter, which is intended 
to represent the requested scope of an access token. I used this pattern in the 
OAuth SCA mode in Berlin Group's PSD API. 

(2) One could also use additional query parameter to add further details re the 
requested authorization, e.g. 

GET /authorize?

&scope=sign

&hash_to_be_signed=

It seems to be robust (easier to implement?) but means the scope only 
represents the static part of the action. The AS needs to look into a further 
parameter to fully understand the requested authorization. 

(3) Open Banking UK utilizes the (OpenID Connect) „claims“ parameter to carry 
additional data. 

Example:  

"claims": {
"id_token": {
"acr": {
"essential": true,
"value": "..."
  },
"hash_to_be_signed": {
"essential": true,
"value": ""
}
},
"userinfo": {
"hash_to_be_signed": {
"essential": true,
"value": ""
}
}
  }

I‘m looking forward for your feedback. Please also indicated whether you think 
we should flush out a BCP on that topic. 

kind regards,
Torsten.

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

Re: [OAUTH-WG] Meeting Invite for the OAuth WG Virtual Office Hours

[Brian Campbell]

I tried to join this morning but was the only one on the webex (of course,
user error could be involved on my part).

I didn't have much specific for the call but did want to politely ask the
Chairs how the document shepherding was coming along for
https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ ?



On Wed, May 16, 2018 at 11:38 AM, Hannes Tschofenig <
hannes.tschofe...@arm.com> wrote:

> Hi all,
>
>
>
> Rifaat and I will again dial into the Webex next Monday to hear whether
> someone of you has anything to discuss/report/suggest/….
>
>
>
> Ciao
> Hannes & Rifaat
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> ___
> 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] Meeting Invite for the OAuth WG Virtual Office Hours

[Rifaat Shekh-Yusef]

Hmmm, I did open webex and waited for 10 minutes :)

I will be traveling this week, but I will discuss it with Hannes in the
coming few days and we will start working on the write-ups for the MTLS and
JWT BCP documents soon.

Regards,
 Rifaat


On Mon, Jun 18, 2018 at 12:48 PM Brian Campbell  wrote:

> I tried to join this morning but was the only one on the webex (of course,
> user error could be involved on my part).
>
> I didn't have much specific for the call but did want to politely ask the
> Chairs how the document shepherding was coming along for
> https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ ?
>
>
>
> On Wed, May 16, 2018 at 11:38 AM, Hannes Tschofenig <
> hannes.tschofe...@arm.com> wrote:
>
>> Hi all,
>>
>>
>>
>> Rifaat and I will again dial into the Webex next Monday to hear whether
>> someone of you has anything to discuss/report/suggest/….
>>
>>
>>
>> Ciao
>> Hannes & Rifaat
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. Thank you.
>>
>> ___
>> 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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Dynamic Scopes

[David Waite]

One of the reasons I hear for people wanting parameterized scopes is to deal 
with transactions. I’d love to hear thoughts from the group on if/how OAuth 
should be used to authorize a transaction, vs authorize access to 
information/actions for a period of time. This approach for instance sounds 
like it is trying to scope down access to a single resource representing a 
transaction to be performed?

I also hear people wanting dynamic scopes to support a finer-grained access 
control, for instance not ‘allow moderation of chat rooms’ but rather the list 
of *specific* rooms. There is sometimes a case to be made that this would be 
better served as local state in the resource, or as the result of an API call, 
but there is value in some use cases to represent this as a finer-grained 
consent to the user.

I’ve seen parameterized scopes take the form of colon-deliminated name:param, 
as a function name(param), or as a URL https://nameurl?param=value.  The latter 
is recommended sometimes in specs like opened connect as a way to prevent 
conflicting vendor extensions.

In terms of requesting a parameterized scope - I prefer overloading scope (or 
perhaps claims when using connect) vs adding a new authorization request 
parameter - for one, use of authorization request parameters limits your grant 
type options unless you also define them as token request parameters for the 
other types. Second, the consent/business logic for determining which scopes a 
client get should already be a customization point for a reusable AS.

-DW

> On Jun 18, 2018, at 9:34 AM, Torsten Lodderstedt  
> wrote:
> 
> Hi all,
> 
> I have been working lately on use cases where OAuth is used to authorize 
> transactions in the financial sector and electronic signing. What I learned 
> is there is always the need to pass resource ids (e.g. account numbers) or 
> transaction-specific values (e.g. amount or hash to be signed) to the OAuth 
> authorization process to further qualify the scope of the requested access 
> token. 
> 
> It is obvious a static scope value, such as „payment“or „sign“, won’t do the 
> job. For example in case of electronic signing, one must bind the 
> authorization/access token to a particular document, typically represented by 
> its hash.
> 
> I would like to get your feedback on what you consider a good practice to 
> cope with that challenge. As a starting point for a discussion, I have 
> assembled a list of patterns I have seen in the wild (feel free to extend). 
> 
> (1) Parameter is part of the scope value, e.g. „sign:“ or 
> "payments:" - I think this is an obvious way to 
> represent such parameters in OAuth, as it extends the scope parameter, which 
> is intended to represent the requested scope of an access token. I used this 
> pattern in the OAuth SCA mode in Berlin Group's PSD API. 
> 
> (2) One could also use additional query parameter to add further details re 
> the requested authorization, e.g. 
> 
> GET /authorize?
> 
> &scope=sign
> 
> &hash_to_be_signed=
> 
> It seems to be robust (easier to implement?) but means the scope only 
> represents the static part of the action. The AS needs to look into a further 
> parameter to fully understand the requested authorization. 
> 
> (3) Open Banking UK utilizes the (OpenID Connect) „claims“ parameter to carry 
> additional data. 
> 
> Example:  
> 
> "claims": {
>"id_token": {
>"acr": {
>"essential": true,
>"value": "..."
>  },
>"hash_to_be_signed": {
>"essential": true,
>"value": ""
>}
>},
>"userinfo": {
>"hash_to_be_signed": {
>"essential": true,
>"value": ""
>}
>}
>  }
> 
> I‘m looking forward for your feedback. Please also indicated whether you 
> think we should flush out a BCP on that topic. 
> 
> 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] Meeting Invite for the OAuth WG Virtual Office Hours

[Hannes Tschofenig]

Rifaat was on the call for 30mins but nobody joined. I couldn’t make it due to 
a delayed flight.

Write-ups are in progress.

Ciao
Hannes


From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: 18 June 2018 18:47
To: Hannes Tschofenig
Cc: 
Subject: Re: [OAUTH-WG] Meeting Invite for the OAuth WG Virtual Office Hours

I tried to join this morning but was the only one on the webex (of course, user 
error could be involved on my part).

I didn't have much specific for the call but did want to politely ask the 
Chairs how the document shepherding was coming along for 
https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ ?



On Wed, May 16, 2018 at 11:38 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:
Hi all,

Rifaat and I will again dial into the Webex next Monday to hear whether someone 
of you has anything to discuss/report/suggest/….

Ciao
Hannes & Rifaat
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
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.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Meeting Invite for the OAuth WG Virtual Office Hours

[Anthony Nadalin]

I was dialed in and no one was there

From: OAuth  On Behalf Of Hannes Tschofenig
Sent: Monday, June 18, 2018 2:06 PM
To: Brian Campbell 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Meeting Invite for the OAuth WG Virtual Office Hours

Rifaat was on the call for 30mins but nobody joined. I couldn’t make it due to 
a delayed flight.

Write-ups are in progress.

Ciao
Hannes


From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: 18 June 2018 18:47
To: Hannes Tschofenig
Cc: mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Meeting Invite for the OAuth WG Virtual Office Hours

I tried to join this morning but was the only one on the webex (of course, user 
error could be involved on my part).

I didn't have much specific for the call but did want to politely ask the 
Chairs how the document shepherding was coming along for 
https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/
 ?



On Wed, May 16, 2018 at 11:38 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:
Hi all,

Rifaat and I will again dial into the Webex next Monday to hear whether someone 
of you has anything to discuss/report/suggest/….

Ciao
Hannes & Rifaat
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
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.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Dynamic Scopes

[Jacob Ideskog]

This borderlines another problem we've been adressing which is when a
client needs to pass on the request to an asyncronous queue. In that case
the client can request the AS to "downscope" it's token, and include a
signature of the request in the token. (simplified).

The dynamic scope approach would help in this case also, i.e. have a
dynamic scope "sign:" which lets the client downscope it by adding the
actual signature/hash of the request to the token endpoint in a refresh
(sign:). Since we then consider sign: to be the downscoped
version of sign:, thus allowing the AS to issue this AT.

Also, one-off scopes are useful in services like pay per view etc, where
you can purchase say a single movie, game etc. Then the dynamic scope can
be decided to be issued by the AS rathern than specifically asked for by
the client. Example client asks for games: and gets
games:world-cup-2018-06-15 etc.

So, the scope approach seems like a more general approach for both the
authorize endpoint as well as the token endpoint. With that said, it will
probably make it hard to narrow down dynamic scopes to single particular
usecase. It would mean that

1. If a dynamic scope is requested on  the Authorize endpoint it's a
consentable request that the user needs to sign
2. If a dynamic scope is requested on the Token endpoint, the AS determines
what the end result might be. Seems a bit vague perhaps.

For OpenID I still think the signed claims parameters make a more flexible
approach, but OpenID isn't always in play.

Just my 5-cents

/Jacob Ideskog
Curity


mån 18 juni 2018 kl 21:00 skrev David Waite :

> One of the reasons I hear for people wanting parameterized scopes is to
> deal with transactions. I’d love to hear thoughts from the group on if/how
> OAuth should be used to authorize a transaction, vs authorize access to
> information/actions for a period of time. This approach for instance sounds
> like it is trying to scope down access to a single resource representing a
> transaction to be performed?
>
> I also hear people wanting dynamic scopes to support a finer-grained
> access control, for instance not ‘allow moderation of chat rooms’ but
> rather the list of *specific* rooms. There is sometimes a case to be made
> that this would be better served as local state in the resource, or as the
> result of an API call, but there is value in some use cases to represent
> this as a finer-grained consent to the user.
>
> I’ve seen parameterized scopes take the form of colon-deliminated
> name:param, as a function name(param), or as a URL
> https://nameurl?param=value.  The latter is recommended sometimes in
> specs like opened connect as a way to prevent conflicting vendor extensions.
>
> In terms of requesting a parameterized scope - I prefer overloading scope
> (or perhaps claims when using connect) vs adding a new authorization
> request parameter - for one, use of authorization request parameters limits
> your grant type options unless you also define them as token request
> parameters for the other types. Second, the consent/business logic for
> determining which scopes a client get should already be a customization
> point for a reusable AS.
>
> -DW
>
> > On Jun 18, 2018, at 9:34 AM, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
> >
> > Hi all,
> >
> > I have been working lately on use cases where OAuth is used to authorize
> transactions in the financial sector and electronic signing. What I learned
> is there is always the need to pass resource ids (e.g. account numbers) or
> transaction-specific values (e.g. amount or hash to be signed) to the OAuth
> authorization process to further qualify the scope of the requested access
> token.
> >
> > It is obvious a static scope value, such as „payment“or „sign“, won’t do
> the job. For example in case of electronic signing, one must bind the
> authorization/access token to a particular document, typically represented
> by its hash.
> >
> > I would like to get your feedback on what you consider a good practice
> to cope with that challenge. As a starting point for a discussion, I have
> assembled a list of patterns I have seen in the wild (feel free to extend).
> >
> > (1) Parameter is part of the scope value, e.g.
> „sign:“ or "payments:" - I think
> this is an obvious way to represent such parameters in OAuth, as it extends
> the scope parameter, which is intended to represent the requested scope of
> an access token. I used this pattern in the OAuth SCA mode in Berlin
> Group's PSD API.
> >
> > (2) One could also use additional query parameter to add further details
> re the requested authorization, e.g.
> >
> > GET /authorize?
> > 
> > &scope=sign
> > 
> > &hash_to_be_signed=
> >
> > It seems to be robust (easier to implement?) but means the scope only
> represents the static part of the action. The AS needs to look into a
> further parameter to fully understand the requested authorization.
> >
> > (3) Open Banking UK utilizes the (OpenID Connect) „claims“