Re: [OAUTH-WG] Dynamic Scopes
> Am 22.06.2018 um 23:08 schrieb George Fletcher : > > 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
Re: [OAUTH-WG] Dynamic Scopes
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 on behalf of Torsten Lodderstedt Sent: Saturday, June 23, 2018 3:43:50 AM To: George Fletcher Cc: Brian Campbell; oauth Subject: Re: [OAUTH-WG] Dynamic Scopes > Am 22.06.2018 um 23:08 schrieb George Fletcher : > > 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. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Dynamic Scopes
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 : > > 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 on behalf of Torsten Lodderstedt > > Sent: Saturday, June 23, 2018 3:43:50 AM > To: George Fletcher > Cc: Brian Campbell; oauth > Subject: Re: [OAUTH-WG] Dynamic Scopes > > > > > Am 22.06.2018 um 23:08 schrieb George Fletcher : > > > > 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
Re: [OAUTH-WG] Dynamic Scopes
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 : 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. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
