eSignature Use Case
Use case:
Step 1: The agent asks the mother to register for mother-child care and opens the UI BB for Registration BB.
Step 2: Mother authenticates herself using biometrics. (ID BB) and provides scope access to e-sign.
Step 3: The child is verified using his/her identification.
Step 4: A form is shown to the mother by the registration bb (UI BB of the registration bb)
Step 5: The agent helps her in filling in the details & explains the terms and conditions.
Step 6: Mother decides to sign the form, terms & conditions and clicks the “Sign using e-signature” button.
Step 7: The UI BB submits to the details to the Registration BB.
Step 8: The Registration BB calls the e-signature BB with an access token from the ID BB.
Step 9: The e-signature BB will call the token to introspect the API of the ID BB.
Step 10: The ID BB returns the user details, user PSUT (Partner Specific User Token) and the scope as consented.
Step 11: The e-signature BB verifies the information, if ok then signs (look for alternate flows) the given Hash in the requested format. The signature would have been timestamped.
Alternate Flow 1:
The e-signature block creates a random signature key which is valid for 5 minutes. Creates certificate with the user details filled in X509 V3.
Alternate Flow 2:
The e-signature block asks the PIN of the user to verify the certificate validity and sign using the QSCD.
Step 12: The e-signature BB would return the signature (as per the requested format) to the registration BB.
Step 13: The registration BB will call the e-signature client-side library to merge the given signature to the document if needed.
Step 14: The e-signature client-side library will return the final document to the Registration BB.
Step 15: The Registration BB would store this signed information and would let the user review and download the signed & completed application.
Logical Process Blueprint
This table describes all the input and output needed from the building blocks.
From BB | To BB | Description | To Input | To Output | Mandatory |
|---|---|---|---|---|---|
e-Signature BB | ID BB | Check if the given access token is valid | access token, client id | validity as per RFC 7662 | Yes |
e-Signature BB | ID BB | Get the user name and age details | Input access token, client id | get user info object as per openid spec | Yes |
e-Signature BB | Payment BB | Redirect & collect the payment | Payment amount | result of payment | No |
e-Signature BB | Payment BB | Check the payment status/result | user id, transaction id | payment result, amount, payment date | No |
Registration BB | e-Signature BB | Register/Onboard the user on QSCD | access token, client id, call back URL, signed jwt | Redirect the browser | Yes |
e-Signature BB | IM BB | Check if the registration BB call back URL is registered. Check if the registration BB is listed | registration bb’s signed JWT request | Yes/No - based on the validity of JWT and client id. | Yes |
Consent BB/Any BB | e-Signature | Sign the hash. | hash, format, user access token, bb’s signed JWT request, type of key (RSA, ECC etc) | Signature, Certificate. | Yes |
Consent BB/Any BB | e-Signature | Check for validity of signature, this service should be available for everyone. | hash, signature, format, user access token (optional) | Yes/No | Yes |
Consent BB/Any BB | e-Signature | Get information about the e-signature building block | None | Signature device support (QSCD, HSM), formats (xaeds …), algorithm (RSA, ECC..), revocation details, timestamp URL, ID BB supported, Supported CA and CA certificate url. | Yes |
Consent BB/Any BB | e-Signature (Client) | Ability to merge the files for embedded signatures | document, hash, format | signed document | Yes |
Sequence diagram
HSM Based Single key per sign
QSCD based signature using PIN/Password
Remote QSCD Onboarding