Feature: A Process for Verifiable Presentation Exchange on Websites using VC-API

[jfelixh]

Presenting Verifiable Credentials to a Third-Party and Connecting the Wallet App to a Web Application

This issue explains the procedure of presenting verifiable credentials to a third party verifier web server, assuming that the credential holder stores his VCs in the DCC Learner Credential Wallet. We expect that a large portion of users might want to use the verifier web application from the comfort of their laptop or PC, while still having their credentials always on hand inside their phone. Therefore, we advocate for a process that is able to work with the combination of PC and phone, but is also able to work from just a phone. To ensure compatibility with other verifiers, VC-API is the basis for this process.

The main difficulty here is that VC-API dictates the exchange to be initiated by the wallet. This works ok for most cases, but as soon as the exchange needs to be attributed to the student login session of a web application (that does not previously know the user's DID), such as a student information system, it breaks. As we do not foresee a completely did-based identity and account management in the near future, the protocol needs to be adapted without compromising compatibility.

Specific Presentation Process

As assumed, the learner stores his VCs in the DCC wallet app. The learner uses a PC to navigate the web application of a third-party verifier. This web application has some identifier for a user session, be it persistent or not. At some point, the learner is prompted to present one or more credentials. One possible example for this process is applying for a study program on a university website.

1. Web Application generates QR Code: This QR code contains all information required for a wallet to initiate the presentation exchange in accordance with the VC-API specification. In this case, that is only the API Endpoint that the wallet is supposed to initiate the exchange with. It always takes the form of /exchanges/<name>. We propose using the "name" part to instead insert a UUID (or similar ID) making it possible for the web application to match the credential presentation exchange to the web session.
2. Wallet App Scans QR Code
3. [VC-API]Initiate: The wallet begins the VC-API-defined presentation process by sending an initiate request like this:

POST /exchanges/<UUID> HTTP/1.1
Host: example.edu
Content-Type: application/json
Accept: application/json, */*
Accept-Encoding: gzip, deflate

4. [VC-API]Verifiable Presentation Request (VPR): As a response to the exchange request, the verifier app requests a verifiable presentation. This request can hold additional information, such as the type of credential(s) that are requested and, most importantly, a server-generated challenge.
5. Credential Selection: The wallet prompts the learner with information on the exchange and lists all credentials of applicable type to choose from. After the user accepts and chooses one or more credentials, the wallet app creates the presentation using the supplied challenge.
6. [VC-API]Verifiable Presentation (VP): Finally, the finished verifiable presentation is sent to the designated verifier endpoint. At this point, the exchange is over, and the web application will probably update accordingly to lead the learner through the rest of the process.

Note: The user could also directly use the mobile device with the wallet app to present the credentials to the third party. In that case, a deep link next to the QR code in step 1 could trigger the rest of the process.