> 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.
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
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!)
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 proo
