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

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