Separate generation of proof and verification in two separate operations, expose method to retrieve proof.

[rauljareno]

Right now, the go-mobile library is allowing to generate the proof (with or without ZK) at the same time that is sending it to the verifier url to be verified and give back a result. For some workflows, this process is done by different operators (one generating the proof and sharing it with the other one that is verifying its validity). We would need then to separate this binded operations in two for allowing this workflow.

[arnaubennassar]

If I understood, what you want is to:

• Have a method to generate the proof
• Have a method to send the already generated proof to the verifier

This sounds good to me, just keep in mind that both methods will need the verifier URL. The first method should then return some sort of identifier and store the proof to retreive it when sending to the verifier. In other words, it adds a bit of complexity but allows to do the hard computation, and then just send the proof when needed.

Could you bravely describe a use case where this would be needed? I can imagine a situation where two verifiers want to verify the exact same thing and this could be a way to avoid recalculating the proof, but it seems a bit odd to find this scenario (keep in mind that proofs are only valid for a period of time defined by the verifier, after this period hey must be recomputed in order to be "fresh" enough)

[rauljareno]

The generation of the proof needs the verifier URL? is not done locally? The use case is for access control for example. User wants to access to some space, then it will generate the proof in the moment of accessing and share this proof with another app that will act as a verifier of this proof, connecting with the verifier url to know if it should allow the access or not.

[arnaubennassar]

In order to generate the proof, there are some artifacts that must be downloaded. This artifacts will be provided by the verifier, so yes, to generate the proof you need the verifier URL. Once this artifacts are downloaded, the proof is generated locally.

I would suggest something like this flow:

1. Holder downloads the artifacts and generate the proof (as it works right now)
2. Verifier sends a token to the holder (this token could be fit in a QR code)
3. The verifier also adds this token to a DB along with other information needed to authenticate the user (photo, ID number, ...)
4. When the user has to pass the access control, they show the QR, the security personal then can scan the QR and fetch the authentication data (photo, ID number, ...) and verify that this info match with the person it has in front.

Note that only point 1 is covered by iden3-mobile, and 2 will require modifications on the library to get the token reply. Points 3 and 4 would be completely out of the scope of this library.

Another option would be:

1. Holder fetch the required artifacts to generate the proof from the verifier
2. Holder generates the proof
3. Holder waits until it's in front of the security personal to actually send the proof

This approach is more similar to what we have now, and would require to split proof generation and proof sending as suggested by this issue. This could get messy as any holder could send the proof at any time (not just when they are in front of the security checkpoint).

As a conclusion, it can be a good idea to split this method in two because it will give more flexibility to integrators, but the most natural way to proceed is to generate the proof just before sending it

[arnaubennassar]

If @rauljareno still think that is a good idea to have this method splitted, I will add an issue to address it.

[AlbertoElias]

@arnaubennassar I don't understand what the token that the verifier sends to the holder is. Could you explain further please? Thanks!

[arnaubennassar]

This token would be a unique identifier. It could be any piece of data that can be used to fetch data from a DB:

1. User shows the token (via QR)
2. Security personal scans QR and uses token to fetch data from a DB (picture, ID number, ...)

Anyway I guess that this is quite specific to your project, and I think this is not the best place to discuss it, I'd like to keep this issue focused on the question is it worth it to split proof generation and proof sending?. My bad for suggesting use case specific flows here.

[arnaubennassar]

Do you find interesting having the capability to send proofs through channels that are not supported directly in the library? Because one option could be generate the proof, export it as a file, and then give the integrator the ability to send it through other channels (random example: send it to a telegram bot)

[AlbertoElias]

We were going to implement exactly that.

1. Holder receives claim + photo.
2. Holder generates proof.
3. Holder saves proof + photo in server X.
4. Holder shows location of server X to verifier.
5. Verifier fetches proof + photo.
6. Verifies does verification process.

So that's why we would need to separate proof generation from verification. And if need anything extra to be able to move the proof to this server ,then yeah, that as well.

Thanks!

[arnaubennassar]

@AlbertoElias In the flow you descrive, in step 5, both the proof and the photo are fetched from server X?

[AlbertoElias]

@arnaubennassar exactly

[arnaubennassar]

Cool in this case it will be also needed to export the proof