Re: [OAUTH-WG] Dynamic Scopes

[George Fletcher <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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 <[e-mail]>:
>> 
>> 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
>> 
>> <uma-signing-rpt.png>
>> 
>>> On 6/24/18 4:27 AM, Torsten Lodderstedt wrote:
>>> 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 <[e-mail]>:
>>> 
>>>> 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
>>>> 
>>>>> On 6/23/18 3:43 AM, Torsten Lodderstedt wrote:
>>>>>> Am 22.06.2018 um 23:08 schrieb George Fletcher <[e-mail]>:
>>>>>> 
>>>>>> 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.
>>>>> 
>>>>> 
>>>> 
>> 
>> -- 
>> Distinguished Engineer                   
>> Identity Services Engineering     Work: [e-mail]
>> AOL Inc.                          AIM:  gffletch
>> Mobile: [phone]           Twitter: http://twitter.com/gffletch
>> Office: [phone]           Photos: http://georgefletcher.photography