The presentation is signed using the holder's private key as it is being created. To validate the presentation, the verifier must also check the issuer's signature and the holder's public key. One way to achieve this is to make the holder have a DID too, so that the verifier can look up the DID on the chain and learn the public key.
The API allows you to create and sign a verifiable presentation out of one or more Verifiable Credentials.
For a detailed example of the presentations workflow. Please refer here.
Create Presentation
The holder while creating the presentation signs it with his private key. For the verifier to verify the presentation, in addition to verifying the issuer's signature, he/she needs to verify this signature as well, and for that he must know the holder's public key.
This is an operation to create and sign a verifiable presentation out of one or more Verifiable Credentials.
Presentation's Challenge in a string format. The default value for this is random hex string. NOTE: if this presentation is being created to respond to a proof-request the challenge should be set to the value from the nonce field in the proof-request.
domain
body
string
false
A domain for the proof in a string format. The default value for the domain is dock.io.
It often makes sense for a verifier to request proof of credentials from a holder. For this, we have built a proof requests system into the API that works with the Dock Wallet. When a request is created, you will receive a URL which you should display in a QR code for a wallet application to scan. You can define which attributes should exist in the credential, a name for the holder and yourself to see and a nonce/challenge which prevents replay attacks.
See the https://identity.foundation/presentation-exchange/#input-descriptor-extensions for more examples, but a few common use cases are:
Require a numeric attribute to be within a range
For example, a verifier might require that the holder have an income between $100,000 and $200,000 per year. This could be requested using the following input_descriptor
For example, a verifier might require that the credential be issued after a certain date. In this example the verifier is requiring that the credential was issued between January 1, 2020 and December 31, 2020.
[ {"id":"f2ea3225-ef6b-44d7-a37c-7713c66875b5","name":"Proof of Bachelors of Education","nonce":"6684fb3d878f2c3a25e35e36045bde8d","verified":false,"created":"2023-04-05T22:00:25.729Z","updated":"2023-04-05T22:00:25.729Z","presentation": {},"response_url":"https://api-testnet.dock.io/proof-requests/f2ea3225-ef6b-44d7-a37c-7713c66875b5/send-presentation","type":"proof-request","qr":"https://creds-testnet.dock.io/proof/f2ea3225-ef6b-44d7-a37c-7713c66875b5","request": {"input_descriptors": [ {"id":"Credential 1","name":"Proof of Bachelors of Education","purpose":"Prove that the holder has a Bachelors of Education degree","constraints": {"fields": [ {"path": ["$.credentialSubject.degreeName","$.credentialSubject.degreeType","$.credentialSubject.dateEarned | date: \"%B %d, %Y\"","$.credentialSubject.fullName" ] }, {"path": ["$.name" ],"filter": {"type":"string","pattern":"Bachelors of Education" } } ] } } ] } }]
Get Proof Request
Get the details of an existing proof request and its verification status.
When working with Proof Requests you will often want to request the same information from holders. To make this easier you can create Proof Request Templates to define the contents of the proof requests to be re-used.
# You can also use wgetcurl-XPOSThttps://api-testnet.dock.io/proof-templates \-H'Content-Type: application/json' \-H'Accept: application/json' \-H'DOCK-API-TOKEN: API_KEY'
# You can also use wgetcurl-XPOSThttps://api-testnet.dock.io/proof-templates/{id}/request \-H'Content-Type: application/json' \-H'Accept: application/json' \-H'DOCK-API-TOKEN: API_KEY'
# You can also use wgetcurl-XPATCHhttps://api-testnet.dock.io/proof-templates/{id} \-H'Content-Type: application/json' \-H'Accept: application/json' \-H'DOCK-API-TOKEN: API_KEY'
