DARS Api - Callback Api
DARS Api
verify/request
The /verify/request service allows you to ask for verifiable credentials to a user
In order to request verifiable credentials to a user, a proof template (or request) must be previously created for the own organization. The proof request can be configured using Dizme Studio (see documentation)
POST /verify/request
Request body:
{
"pd_id": "string",
"allow_multiple_read": true,
"request_uid": "string"
}
pd_id : business code of the proof template configured on Dizme Stack.
By example PROOF_01 business code
allow_multiple_read : true value consent to scan many time the same qrcode from several users
request_uid : must be set with an own generated unique identifier for the request, if the attribute is omitted, a unique identifier will be automatically generated
Example Response body:
{
"request_uid": "12345-12345-12345",
"verification_link": "https://agent.dizme.io/api/v1/invitation/12345-12345-12345"
}
request_uid : the unique identifier of the request already sent or generated by the system.
verification_link: url to be embended into ar qrcode/or to send to the user via other method (sms, email, webpage)
verify/complete
With this service an organization can complete a verification activity optionally adding the check result on the data received.
Usually after a confirm verify with a success response an organization makes some business logic check or operation. Based on the result of this operation the organization can decide to confirm the success of the verification or the verification. Optionally can added a info message to be shown to the user or a subsequent credential offer link
POST /verify/complete
Request body:
{
"presentation_id": "string",
"status": "string", /* OK - FAILED */
"reason": "string",
"messages": [
{
"lang": "string",
"body": "string"
"title": "string"
},
],
"available_actions":[
{
"action":"ISSUE"
"data": {
"credential_offer_link" : "...."
}
}
]
}
presentation_id : is a unique identifier for a specific outcome of a verification. This value will be received through the verify/event callback.
messages : this will be shown to the user when the wallet receive the result.
available_actions : possible next actions that can be request to the wallet.
ISSUE - VERIFY -
status :
OK - if the organization confirms a successful verification for credential
Example for notification status in wallet
FAILED - if the organization refuse/reject credential data
Example for notification status in wallet
descriptions : list of messages description in various language
verify/report
The service allows to retrieve a verify report with the presentation definition, the verifiable presentation with the data sent from the wallet.
POST /verify/report/{presentation_id}
Example Response body:
{
"request_uid": "string",
"pd": {}
"vp": {},
"credential_data:credential_data": []
}
request_uid : the unique identifier of the request already sent or generated by the system.
pd : presentation definition request to the wallet
vp : verifiable presentation sent frm the wallet
credential_data : credentials data extracted sent from the wallet
credential/offer
The service allows to create a credential offer. The offer can be sent through a pairwise connection (using connection_id).
POST /credential/offer
Request body for Certified Credential:
{
"request_uid": "string",
"credential_def_refs": ["cred_id1","cred_id2",...], (optional)
"vcs": [
{
"vc": {
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://purl.imsglobal.org/spec/ob/v3p0/context.json"
],
"id": "urn:uuid:THIS WILL BE REPLACED WITH DYNAMIC DATA FUNCTION (see below)",
"type": [
"VerifiableCredential",
"OpenBadgeCredential"
],
"name": "JFF x vc-edu PlugFest 3 Interoperability",
"issuer": {
"type": [
"Profile"
],
"id": "did:key:THIS WILL BE REPLACED WITH DYNAMIC DATA FUNCTION FROM CONTEXT (see below)",
"name": "Jobs for the Future (JFF)",
"url": "https://www.jff.org/",
"image": "https://w3c-ccg.github.io/vc-ed/plugfest-1-2022/images/JFF_LogoLockup.png"
},
"issuanceDate": "2023-07-20T07:05:44Z (THIS WILL BE REPLACED BY DYNAMIC DATA FUNCTION (see below))",
"expirationDate": "WILL BE MAPPED BY DYNAMIC DATA FUNCTION (see below)",
"credentialSubject": {
"id": "did:key:123 (THIS WILL BE REPLACED BY DYNAMIC DATA FUNCTION (see below))",
"type": [
"AchievementSubject"
],
"achievement": {
"id": "urn:uuid:ac254bd5-8fad-4bb1-9d29-efd938536926",
"type": [
"Achievement"
],
"name": "JFF x vc-edu PlugFest 3 Interoperability",
"description": "This wallet supports the use of W3C Verifiable Credentials and has demonstrated interoperability during the presentation request workflow during JFF x VC-EDU PlugFest 3.",
"criteria": {
"type": "Criteria",
"narrative": "Wallet solutions providers earned this badge by demonstrating interoperability during the presentation request workflow. This includes successfully receiving a presentation request, allowing the holder to select at least two types of verifiable credentials to create a verifiable presentation, returning the presentation to the requestor, and passing verification of the presentation and the included credentials."
},
"image": {
"id": "https://w3c-ccg.github.io/vc-ed/plugfest-3-2023/images/JFF-VC-EDU-PLUGFEST3-badge-image.png",
"type": "Image"
}
}
}
},
"mapping": {
"id": "<uuid>",
"issuer": {
"id": "<issuerDid>"
},
"credentialSubject": {
"id": "<subjectDid>"
},
"issuanceDate": "<timestamp>",
"expirationDate": "<timestamp-in:365d>"
},
"selectiveDisclosure": {
"fields": {
"name": {
"sd": true
}
}
}
}
],
"comment": "string"
}
Example for credential values :
request_uid : must be set with an own generated unique identifier for the request, if the attribute is omitted, a unique identifier will be automatically generated
credential_def_refs : list of reference of the credentials to issue (optional)
vcs : json schema of the credential filled with the value to issue.
Example Response body:
{
"request_uid": "string"
"credential_offer_link": "string"
}
request_uid : the unique identifier of the request already sent or generated by the system.
credential_offer_link :
Callback API
verify/event
Upon invocation of this service, all the attributes requested in the verify request will be received.
POST /verify/event
Request body:
{
"request_uid": "string",
"status" : "string"
"presentation_id": "string"
}
example of revealed attribute :
revealed_attributes : {“attribute1”:”value”, “attribute2”:”value}
proof_business_code : business code of the proof template configured.
By example PROOF_01 is configured
request_uid :
is a unique identifier of the verify request
presentation_id : is a unique identifier for a specific outcome of a verification.
credential/offer/event
Send the confirm for an issued credential
POST /credential/offer/event
Request body:
{
"request_uid": "string",
"credential_def_id": "string",
"tid": "string",
"status": "string"
}
connection_id : is a unique identifier for a specific connection with an user wallet. This value will be received through the connection notify callback.
credential_ref_id : id of the credential issued
tid : transaction id of the issue
request_uid :
is a unique identifier of the request that triggered the offer
status:
READ
DOWNLOADED
REJECTED
FAILURE