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 protected]>: > > 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 protected]> >> 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 <[email protected]>: >>> >>> 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 <[email protected]>: >>>> >>>>> 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 <[email protected]>: >>>>>>> >>>>>>> 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: [email protected] >>> AOL Inc. AIM: gffletch >>> Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch >>> Office: +1-703-265-2544 Photos: http://georgefletcher.photography
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
