Subject: [OAUTH-WG] Dynamic Scopes

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 18 Jun 2018 17:34:05 +0200

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:<hash_to_be_signed>“ or "payments:<payment_resource_id>" - 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=<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": "<hash_to_be_signed>"
        }
    },
    "userinfo": {
        "hash_to_be_signed": {
            "essential": true,
            "value": "<hash_to_be_signed>"
        }
    }
  }

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.

---

From: David Waite <[email-masked]>
Date: Mon, 18 Jun 2018 12:59:34 -0600

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 <[email-masked]> wrote:
> 
> Hi all,
> 
> ....
> ....
> Torsten._______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Jacob Ideskog <[email-masked]>
Date: Tue, 19 Jun 2018 08:16:39 +0200

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:<hash>). Since we then consider sign:<hash> 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 <[email-masked]>:

> 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
>
> > 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:<hash_to_be_signed>“ or "payments:<payment_resource_id>" - 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.
> >
> > 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.
> >
> > I‘m looking forward for your feedback. Please also indicated whether you
> think we should flush out a BCP on that topic.
> >
> > kind regards,
> _______________________________________________
> OAuth mailing list
> [email-masked]
-- 
---
Jacob Ideskog
Curity AB

M: +46(0)70 22 33 664
E: [email-masked] <[email-masked]>
W: curity.io

*Curity AB is the leading supplier of API-driven identity
management, providing unified security for digital services. Curity
Identity Server is the world’s most powerful OAuth and OpenID Connect
Server; it is used for logging in and securing millions of users’ access to
web and mobile apps over APIs and microservices. We enjoy the trust of
large organizations in financial services, telecom, retail, energy and
government services with operations across many countries which have chosen
Curity for their enterprise-grade API security needs. *

*More information about us can be found at: https://curity.io
<https://curity.io/> *

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 19 Jun 2018 14:53:31 +0200

Hi Jacob,

thanks for your thoughts on dynamic scopes. 

> Am 19.06.2018 um 08:16 schrieb Jacob Ideskog <[email-masked]>:
> 
> For OpenID I still think the signed claims parameters make a more flexible approach, but OpenID isn't always in play.

Why do you think it is more flexible? 

kind regards,
Torsten.

---

From: Brian Campbell <[email-masked]>
Date: Wed, 20 Jun 2018 15:58:05 -0600

In my own personal and humble opinion, Torsten, what you describe as "(1)
Parameter is part of the scope value" is the most natural approach and
works without needing changes to, or going outside of, RFC6749 The OAuth
2.0 Authorization Framework. There may be AS implementations that have made
assumption about scope values being static (I know of at least one!) but
that's an implementation/feature issue, which can change, and not a spec
issue.

The OIDC "claims" parameter is already a bit of a hairy beast and I think
using it and the ID Token to convey more dynamic access/authorization is
blurring the line between authorization and authentication a bit much.
Also, as others have pointed out, OIDC isn't always in play - particularly
for regular old authorization cases.

An additional query parameter might be simple for a one-off case but it's
nonstandard and not very repeatable.

On Mon, Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt <
[email-masked]> wrote:

> 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
> (1) Parameter is part of the scope value, e.g. „sign:<hash_to_be_signed>“
> or "payments:<payment_resource_id>" - 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.
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 21 Jun 2018 17:35:29 +0900

It depends on the use case but if you are talking about payment etc.,
putting the transaction details in the scope and sending it over the
regular RFC6749 redirect to the authorization server is inherently a bad
idea, as it is not protected.

My preference by far is to set up a staging endpoint and push the
transaction intent into there. Then, do the authorization on that staged
transaction. Once that's done. I am OK with putting the reference to the
staged transaction in the scope parameter.

The beauty of the "staging" strategy is that:

1) You can push pretty big payload to the staging endpoint as it is a
server to server thing;
2) You can do the "auth" and then later "capture" after shipping the
product strategy using the access token the client has obtained;
3) The content of the transaction is not exposed via URL nor referrers.

Best,

Nat

On Thu, Jun 21, 2018 at 6:59 AM Brian Campbell <bcampbell=
[email-masked]> wrote:

> .....
>> .....
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> [email-masked]
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 22 Jun 2018 18:28:42 +0200

Hi Nat,

> Am 21.06.2018 um 10:35 schrieb Nat Sakimura <[email-masked]>:
> 
> It depends on the use case but if you are talking about payment etc., putting the transaction details in the scope and sending it over the regular RFC6749 redirect to the authorization server is inherently a bad idea, as it is not protected. 

Good point. One could carry the scope parameter as part of a signed request object to cope with that issue. What do you think about that?

> 
> My preference by far is to set up a staging endpoint and push the transaction intent into there. Then, do the authorization on that staged transaction. Once that's done. I am OK with putting the reference to the staged transaction in the scope parameter. 
> 
> 1) You can push pretty big payload to the staging endpoint as it is a server to server thing; 
> 2) You can do the "auth" and then later "capture" after shipping the product strategy using the access token the client has obtained; 

I agree. That’s really powerful. But one should also admit the client needs to prepare and send two more requests. In OB UK the client first obtains an access token using the client credentials grant and then creates the payment/account information resource. 

best regards,
Torsten. 

> 
> Best, 
> 
> Nat
> 
> 
> 
> On Thu, Jun 21, 2018 at 6:59 AM Brian Campbell <bcampbell=[email-masked]> wrote:
> In my own personal and humble opinion, Torsten, what you describe as "(1) Parameter is part of the scope value" is the most natural approach and works without needing changes to, or going outside of, RFC6749 The OAuth 2.0 Authorization Framework. There may be AS implementations that have made assumption about scope values being static (I know of at least one!) but that's an implementation/feature issue, which can change, and not a spec issue.
> 
> The OIDC "claims" parameter is already a bit of a hairy beast and I think using it and the ID Token to convey more dynamic access/authorization is blurring the line between authorization and authentication a bit much. Also, as others have pointed out, OIDC isn't always in play - particularly for regular old authorization cases.  
> 
> An additional query parameter might be simple for a one-off case but it's nonstandard and not very repeatable. 
> 
> 
> On Mon, Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt <[email-masked]> wrote:
> Hi all,
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 22 Jun 2018 12:56:39 -0400

Hi Torsten,

Re: using request object

Carrying the scope parameter in the request object solves the integrity
issue. However, it does not solve the confidentiality issue unless you also
encrypt it, and encryption is not so easy.

Re: 2 extra roundtrips
You can actually cut the extra roundtrips to one. In fact, you probably
want to have the staging object to be signed to have it work as an evidence
when something goes wrong, so you could rely on that for the client
authentication purpose and that will be more efficient, IMHO. Yes, that
will become essentially the request_uri model.

Cheers,

Nat

2018年6月22日金曜日、Torsten Lodderstedt<[email-masked]>さんは書きました:

> Good point. One could carry the scope parameter as part of a signed
> request object to cope with that issue. What do you think about that?
>
> >
> I agree. That’s really powerful. But one should also admit the client
> needs to prepare and send two more requests. In OB UK the client first
> obtains an access token using the client credentials grant and then creates
> the payment/account information resource.
>
> best regards,
> Torsten.
>
> >
> > Best,
> >
> > Nat
> >
> >
> >
> > In my own personal and humble opinion, Torsten, what you describe as
> "(1) Parameter is part of the scope value" is the most natural approach and
> > The OIDC "claims" parameter is already a bit of a hairy beast and I
> think using it and the ID Token to convey more dynamic access/authorization
> is blurring the line between authorization and authentication a bit much.
> > An additional query parameter might be simple for a one-off case but
> it's nonstandard and not very repeatable.
> >
> >
> > CONFIDENTIALITY NOTICE: This email may contain confidential and
> your computer. Thank you._______________________________________________
> > OAuth mailing list
> > [email-masked]

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: George Fletcher <[email-masked]>
Date: Fri, 22 Jun 2018 13:51:07 -0400

I like the concept of parameterized scopes but I'm not sure they should 
be used for per-transaction use cases. It seems like the use cases 
presented are about operating on parameters specific to the transaction. 
Why are these part of the authorization flow?

Is the goal to bind an access token to a particular transaction? If this 
is the case, would it not be better to either extend the refresh_token 
flow or may better yet, create a new grant_type that takes the 
refresh_token and additional "binding" parameters and then have that 
return the "bound" access token to be used for the transaction.

Maybe this is similar to what Nat is describing with the staging API?

Thanks,
George

On 6/20/18 5:58 PM, Brian Campbell wrote:
> "(1) Parameter is part of the scope value" is the most natural 
> approach and works without needing changes to, or going outside of, 
> RFC6749 The OAuth 2.0 Authorization Framework. There may be AS 
> implementations that have made assumption about scope values being 
> static (I know of at least one!) but that's an implementation/feature 
> issue, which can change, and not a spec issue.
>
> think using it and the ID Token to convey more dynamic 
> access/authorization is blurring the line between authorization and 
> authentication a bit much. Also, as others have pointed out, OIDC 
> isn't always in play - particularly for regular old authorization cases.
>
> On Mon, Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt 
> <[email-masked] <mailto:[email-masked]>> 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).
>
>     „sign:<hash_to_be_signed>“ or "payments:<payment_resource_id>" - 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
>     .....
>     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.
>
>     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.
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and 
> review, use, distribution or disclosure by others is strictly 
> prohibited..  If you have received this communication in error, please 
> notify the sender immediately by e-mail and delete the message and any 
> file attachments from your computer. Thank you./
>
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 22 Jun 2018 22:31:45 +0200

Hi George, 

> Am 22.06.2018 um 19:51 schrieb George Fletcher <[email-masked]>:
> 
> I like the concept of parameterized scopes but I'm not sure they should be used for per-transaction use cases. It seems like the use cases presented are about operating on parameters specific to the transaction. Why are these part of the authorization flow?

The access token is good for a certain transaction only. In case of a electronic signature, the access token is bound to a certain document or a set of documents.

> 
> Is the goal to bind an access token to a particular transaction? If this is the case, would it not be better to either extend the refresh_token flow or may better yet, create a new grant_type that takes the refresh_token and additional "binding" parameters and then have that return the "bound" access token to be used for the transaction.

What would be the scope of such a refresh token? 

> Maybe this is similar to what Nat is describing with the staging API?

The staging API represents the data of a certain transaction in a resource, which allows to parametrize the scope just with the identifier of that resource. So the transaction data can be transmitted in a robust fashion. 

best regards,
Torsten. 

>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. 
>>

---

From: George Fletcher <[email-masked]>
Date: Fri, 22 Jun 2018 17:08:04 -0400

> What would be the scope of such a refresh token?
I would think that the scope issued to the refresh_token could represent 
the category or class of authorizations the refresh_token should be able 
to perform. For example, the kind of transactions that can be bound to 
access tokens. The scope issued into the access_token could be one of 
the "parameterized" ones. But maybe I'm not fully understanding the use 
case :)

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 23 Jun 2018 09:43:50 +0200

> Am 22.06.2018 um 23:08 schrieb George Fletcher <[email-masked]>:
> 
> I would think that the scope issued to the refresh_token could represent the category or class of authorizations the refresh_token should be able to perform. For example, the kind of transactions that can be bound to access tokens. The scope issued into the access_token could be one of the "parameterized" ones. But maybe I'm not fully understanding the use case :)

Let me try to explain ;-)

The client is an issuance company wanting the customer to electronically sign a new contract (legally binding!). Signing in the end means to send a request containing the hash of the document to an API. The API will respond with an CM/S Object containing signature, certificate etc that the client will embedded in the contract document (typical PDF).

We want the user to authorize the signing request using their bank as IDP/AS. Therefore the client sends the OAuth authorization request to the AS. The actual signing request needs to be bound to client, user AND hash (document) in order to prevent fraud. Regulation (eIDAS) requires to always demonstrate the sole control of the user over the whole process. The AS therefore binds (scopes) the access token to exactly this single document/signing request. If the client wants the user to sign another document, it needs to got through the whole process again.

One could think about a general signing permission represented by a refresh token, but not in the high assurance level cases I‘m looking into.

Hope that helps,
Torsten.

---

From: n-sakimura <[email-masked]>
Date: Sat, 23 Jun 2018 13:13:18 +0000

Torsten,

For the digital signature case, I feel a bit uneasy to sign the hash that was sent by the client. The signing mechanism, a bank in this case, should display what is being signed to the user before the user makes a signature. The staging strategy works here as well. The client sends the signed document to the staging server and the bank verifies the signature and shows the document to the user, where the user can view the document and when he decides to sign it, the signature over the document’s hash will be made so that it will result in a mutually signed document.

Best,

Nat

Nat Sakimura
このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、送信者にご連絡のうえ、このメールを削除してくださいますようお願い申し上げます。

PLEASE READ：This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail.
________________________________
From: OAuth <[email-masked]> on behalf of Torsten Lodderstedt <[email-masked]>
Sent: Saturday, June 23, 2018 3:43:50 AM
To: George Fletcher
Cc: Brian Campbell; oauth
Subject: Re: [OAUTH-WG] Dynamic Scopes

We want the user to authorize the signing request using their bank as IDP/AS.. Therefore the client sends the OAuth authorization request to the AS. The actual signing request needs to be bound to client, user AND hash (document) in order to prevent fraud. Regulation (eIDAS) requires to always demonstrate the sole control of the user over the whole process. The AS therefore binds (scopes) the access token to exactly this single document/signing request. If the client wants the user to sign another document, it needs to got through the whole process again.

Hope that helps,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 23 Jun 2018 16:41:43 +0200

Hi Nat,

I thought the same when we started this endeavor.

What I learned is this has privacy/confidentiality implications since the AS learns the content of the document. For example, sending the document to a staging API also requires a consent of the user (given prior to the data transfer!) in case PII is contained in the document.

Moreover, depending on the format of the document, the AS needs different viewers, which increases complexity.

So the current concept (which is also standard practice in this sector) is the client shows the prepared and signed document before and after the signing process and is legally obliged to do it correctly.

The AS is responsible for providing the signing service with verified person data and captures the user‘s intent to sign. Both require consent.

best regards,
Torsten.

> Am 23.06.2018 um 15:13 schrieb n-sakimura <[email-masked]>:
> 
> Torsten,
>

---

From: George Fletcher <[email-masked]>
Date: Sat, 23 Jun 2018 15:07:58 -0400

Thanks Torsten.

I think I have a solution :) Just to make sure I have the flow correct...

Assumption: Using a mobile client

1. User (using their mobile client) attempts to sign a document with the 
insurance company
2. Insurance company redirects the user to their Bank asking for 
identity proof, and signing of specific documents
3. User interacts with Bank to get authorization for the specific 
transaction
4. Mobile client submits request to insurance company using token that 
is specific to the user, document etc.

This is effectively the UMA 2.0 flow [1]

1. Mobile client attempts to invoke resource at the insurance company
2. Insurance company registers the request with UMA AS (the bank in this 
case) and gets a permissions ticket
3. Insurance company instructs mobile client to contact the bank
4. Mobile client contacts the bank specifying the permissions ticket
5. User meets banks requirements for the specific transaction (claims 
interaction)
6. Bank issues mobile client the RPT (token)
7. Mobile client invokes resource at insurance company with RPT

Note that the insurance company can specify the necessary bits that need 
to be in the token when it interacts with the Bank (as the UMA AS). 
[There might be some profiling required here]

I think it's worth exploring whether UMA will solve this use case.

Thanks,
George

[1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 24 Jun 2018 10:27:02 +0200

Hi George,

how is the dynamic nature (hash) of the authorization request handled in your solution?

Note: the signing service is not provided by the insurance company but a third party, a sol-called trusted service provider. The insurance company as the client in this flow sends the request to this provider.

best regards,
Torsten.

> Am 23.06.2018 um 21:07 schrieb George Fletcher <[email-masked]>:
> 
> Thanks Torsten.
> 
> 1. User (using their mobile client) attempts to sign a document with the insurance company
> 2. Insurance company redirects the user to their Bank asking for identity proof, and signing of specific documents
> 3. User interacts with Bank to get authorization for the specific transaction
> 4. Mobile client submits request to insurance company using token that is specific to the user, document etc.
> 
> 2. Insurance company registers the request with UMA AS (the bank in this case) and gets a permissions ticket
> 5. User meets banks requirements for the specific transaction (claims interaction)
> Note that the insurance company can specify the necessary bits that need to be in the token when it interacts with the Bank (as the UMA AS). [There might be some profiling required here]
>

---

From: George Fletcher <[email-masked]>
Date: Sun, 24 Jun 2018 16:01:56 -0400

Not sure I have the flow exactly correct... here is an attempt to define 
a flow based on UMA. It's a little difficult to label which flows are 
which parts of the specs. Specifically I am using...

https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html
https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-05.html

If you want the see the image... take the following text and load it 
into https://www.websequencediagrams.com/

title Signing Sequence

participant "Browser" as B
participant "Insurer" as I
participant "Signer" as S
participant "Bank\n(UMA AS)" as A

B->I: complete process
I->S: sign doc\n(required params)
S->A: permission req\n(what the signer needs)
A->S: permission ticket
S->I: Not authorized\n(AS + permission tckt)
I->A: request RPT\n(permission tckt)
A->I: need_info
I-->B: redirect
B->A: claims interaction endpoint
A->B: user verification & consent
B->A: user meets required claims
A-->B: redirect
B->I: user met claimns\n(permission tckt)
I->A: request RPT\n(permission tckt)
A->I: RPT issued
I->S: sign doc\n(RPT)
S->A: introspect\n(RPT)
A->S: permissions\n(required params)
S->I: Signed doc

On 6/24/18 4:27 AM, Torsten Lodderstedt wrote:
> Note: the signing service is not provided by the insurance company but 
> a third party, a sol-called trusted service provider. The insurance 
> company as the client in this flow sends the request to this provider.
>
> best regards,
> Torsten.
>
> Am 23.06.2018 um 21:07 schrieb George Fletcher <[email-masked] 
> <mailto:[email-masked]>>:
>
>> Thanks Torsten.
>>
>> 4. Mobile client submits request to insurance company using token 
>> that is specific to the user, document etc.
>>
>> Note that the insurance company can specify the necessary bits that 
>> need to be in the token when it interacts with the Bank (as the UMA 
>> AS). [There might be some profiling required here]
>>
>>>> Am 22.06.2018 um 23:08 schrieb George Fletcher<[email-masked]>:
>>>>

-- 
Distinguished Engineer
Identity Services Engineering     Work: [email-masked]
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 27 Jun 2018 11:22:04 -0500

Hi George,

thanks a lot for investing the time to assemble this flow description!

If I got it right the idea is to move the definition of the required permissions (scope) 
of the requested access token to the interaction between signing service and authz service
when the permission ticket is obtained as reaction to the attempt of the client (the insurance 
company) to sign a document. So the client does not need to know what scope to request.
It instead uses the permission ticket (minted by the RS and the AS) to request the needed 
permissions. 

Is that correct?

best regards,
Torsten.

> Am 24.06.2018 um 15:01 schrieb George Fletcher <[email-masked]>:
> 
> Not sure I have the flow exactly correct... here is an attempt to define a flow based on UMA. It's a little difficult to label which flows are which parts of the specs. Specifically I am using...
> 
> If you want the see the image... take the following text and load it into https://www.websequencediagrams.com/
> 
> title Signing Sequence
>

---

From: George Fletcher <[email-masked]>
Date: Wed, 27 Jun 2018 13:13:33 -0400

Yes, that is the basic idea and matches the UMA flow. I think some profiling of UMA is required but may be good place to start.

Thanks,
George

--
Identity Standards Architect
Identity Engineering 
Oath

> On Jun 27, 2018, at 12:22 PM, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Hi George,
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 28 Jun 2018 13:37:59 -0500

Hi George,

I‘m intrigued by the idea to encapsulate scope preparation and resource identification 
into the RS. This seems to be a viable pattern to implement transaction-oriented 
authorization.

I‘m not sure whether this justifies the implementation of UMA 2.0 in AS (additional 
grant types, claims interaction endpoint, endpoints for RS/AS interactions), 
RS and client. 

I think the basic idea could also be utilized by preparing a transaction-specific 
scope value when the client calls the RS for the first time. The client could 
then pass this value in the scope parameter as part of a standard authz code 
grant type authz request.

Does this sound reasonable?

best regards,
Torsten.

> Am 27.06.2018 um 12:13 schrieb George Fletcher <[email-masked]>:
>