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 <tors...@lodderstedt.net> > 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 <gffle...@aol.com>: >> >> 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 <gffle...@aol.com>: >>> >>>> 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 <gffle...@aol.com>: >>>>>> >>>>>> 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: george.fletc...@teamaol.com >> AOL Inc. AIM: gffletch >> Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch >> Office: +1-703-265-2544 Photos: http://georgefletcher.photography
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
