Scope

Owned by sasi
Last updated: Jun 20, 2023
3 min read

Phase 1:

Limit the scope of work to the following

  • Ability to create and manage keys in remote QSCD.

    • This is needed to support the server-side signing of documents. Mostly used by applications without much user involvement.

    • Use cases like Payroll signing, agreement signing etc are handled using this API. Does not require an individual or would not interact with the ID building block.

  • Ability to create & sign using dynamic short-lived keys in remote HSM.

    • This is needed to support the ID BB-based signature. Mostly used by the end user to sign documents or by the applications on behalf of the end user and sign.

    • Use cases like consent, tax filing, request for registration etc can be handled.

  • Support for the following signature formats:

    • XAdES

    • CAdES

    • ASIC

    • JWS (RFC 7515)

    • PAdES

  • No administrative APIs are needed to cater to this requirement. So administrative APIs will be left out of the scope

  • Client-side libraries to be provided to merge the signature with payload ( PDF, XML & JSON)

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

 

Attached is the board that’s used in the GitBook Description.