[auth-service] - Modify registration and signing verification logic

[kkzeng]

Goals

As a developer, I want to ensure that FIDO verification concepts are used to register and authenticate users.

Changes

Overview:

• Changes to generateChallenge to be like /registerOptions to provide authenticator options.
• Changes to PUT consent/{ID}
• Changes to verifySignature()
• Changes to thirdPartyRequests/transactions/authorizations
• Credential interface must change to allow for additional data
• Implement /registerResponse (for registration) and /signingResponse (for transactions)
• Replace verifySignature() function with one that takes more params and uses fido2lib
• New dependency on https://www.npmjs.com/package/fido2-lib (Use https://www.npmjs.com/package/patch-package to patch the node module to accept Android authenticators)

Changes to generateChallenge endpoint
Include other params like algorithm, rpId, rpName, challenge size.
Other than challenge, specifies those params for authenticator (FIDO client)
Needs changes to the model to specify those params (specified later on) - perhaps challenge object can be augmented to have those fields?

Changes to PUT consent/{ID}
Signature validation does not occur here based on TOFU model

Changes to verifySignature()
Instead, use fido2lib to handle FIDO verification - ensures origin, rpid, authenticator etc.
It will also verify signature over clientData and authData properly

Credential Interface

Challenge object will not have a signature for registration phase (during account linking)
ConsentCredential interface must be changed to store:

• prev counter - to prevent authenticator duplication
• aaguid - id to identify authenticator
• public key in PEM format
• credential id (key handle) already exists as credentialId field so no changes needed for this

Changes to thirdPartyRequests/transactions/authorizations
Introduce something similar to /signingOptions to specify similar things as to what generate challenge would have provided.

From a sequence diagram perspective...

Linking

Current Flow:

• POST consents/{ID}/generateChallenge
• auth-service adds credential object which contains a challenge
• Credential object signature, credentialId and public key is filled in by PISP

Changes:

• generateChallenge (which may be renamed) will provide some object like credentialOptions or attestationOptions which could specify attestation options for the authenticator.
• The PISP will not fill in a signature and will fill in the other fields, a new object called attestationResponse which contains public key and other things

Transfer

Current Flow:

• POST thirdpartyrequests/transactions
• PISP checks the quote with the user and signs it with FIDO client
• PUT /authorizations/{ID} with the signature

Changes:

• After posting the thirdPartyRequests/transactions, the user should receive some signingOptions
• What is returned to the auth-service should also be different - should have a bunch of other things produced by the authenticator that are included in AttestationResponse
• Verification logic changes to use fido2lib package

[lewisdaly]

Hey @kkzeng - a couple clarifying questions:

generateChallenge (which may be renamed) will provide some object like credentialOptions or attestationOptions which could specify attestation options for the authenticator.

So the auth-service will still specify something to the authenticator, just not the challenge. Is that correct?

Include other params like algorithm, rpId, rpName, challenge size.
Other than challenge, specifies those params for authenticator (FIDO client)
Needs changes to the model to specify those params (specified later on) - perhaps challenge object can be augmented to have those fields?

Can we specify what those params will be now in the API? Or is that something that a Mojaloop Hub or DFSP running their own auth service will want to specify?

After posting the thirdPartyRequests/transactions, the user should receive some signingOptions

So the PISP app will need to get some other options before signing and sending a PUT /authorizations/{id}? Is that something that could be cached? Or will it need to be fetched every time from the auth service before signing a transaction?

[kkzeng]

Hey @lewisdaly thanks for the great questions!

(1) The auth-service will specify something to the authenticator - including the challenge. For some reason, the registration process still uses the challenge but it doesn't verify any signature. It just compares equality it seems and uses it as some kind of identifier?

(2) Yeah, we can specify the params now - if you reference the fido2 client plugin. We can see what the client needs in order to begin the registration as well as signing later on.

However, I'm not quite sure I have the context to be able to say whether or not we want the Mojaloop Hub/DFSP to specify.

(3) If you refer to the fido2 client plugin, the only option needed to be sent seems to be the relying party domain which we can theoretically just hardcode.

Please let me know if this is all clear enough!

[kkzeng]

To be more specific for (2).
For registration, the following params:

String challenge,
String userId,
String username,
String rpDomain,
String rpName,
int coseAlgoValue

and for signing, only the rpDomain is needed.

However, I'm currently looking into whether or not username and userId are necessary since I'm not sure what these would mean in the context of the relationship between the auth-service and PISP. I guess it could refer to the DFSP account(s) that the Consent contains?