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. >> >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
