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 /verifier/request
Request body:
{
"pd_id": "proof01",
"callback": {
"type": "POST",
"url": "https://bla.com",
"authProfile": "AUTH1"
}
}
pd_id : business code of the proof template configured on Dizme Stack.
By example PROOF_01 business code
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:
{
"pd_uri": "openid4vp://",
"request_uid": "12345-12345-12345"
}
request_uid : the unique identifier of the request already sent or generated by the system.
pd_uri: url to be embended into ar qrcode/or to send to the user via other method (sms, email, webpage)
verify/request/multiple-use
The /verify/multiple-use service allows you to ask for verifiable credentials to users in a static multiple use.
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 /verifier/request/multiple-use
Request body:
{
"pd_id": "proof01",
"callback": {
"type": "POST",
"url": "https://bla.com",
"authProfile": "AUTH1"
}
}
pd_id : business code of the proof template configured on Dizme Stack.
By example PROOF_01 business code
Example Response body:
{
"verify_request_url": "https://...",
"multipleuse_request_uid": "uuid"
}
multipleuse_request_uid : the unique identifier of the request already sent or generated by the system.
verify_request_url: 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:
{
"request_uid": "string",
"status": "string", /* OK - FAILED */
"reason": "string",
"messages": [
{
"lang": "string",
"body": "string"
"title": "string"
},
],
"available_actions":[
{
"action":"ISSUE"
"data": {
"credential_offer_link" : "...."
}
}
]
}
request_uid : 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.
GET /verify/report/{request_uid}
Example Response body:
{
"request_uid": "string",
"multipleuse_request_uid": "string",
"status": "string",
"pd": {},
"vp": {}
}
multipleuse_request_uid : the unique identifier of the request already sent or generated by the system.
request_uid : the unique identifier of the multiple use request already sent or generated by the system.
pd : presentation definition request to the wallet
vp : verifiable presentation sent frm the wallet
verify/reportstatus
The service allows to retrieve a verify status with the presentation definition, the verifiable presentation with the data sent from the wallet.
GET /verify/status/{request_uid}
Example Response body:
{
"request_uid": "string",
"multipleuse_request_uid": "string",
"status": "string",
"pd": {},
"vp": {}
}
multipleuse_request_uid : the unique identifier of the request already sent or generated by the system.
request_uid : the unique identifier of the multiple use request already sent or generated by the system.
pd : presentation definition request to the wallet
vp : verifiable presentation sent frm the wallet
credential/offer
The service allows to create a credential offer.
POST /issuer/request/jwt
Request body for Certified Credential:
{
"callback": {
"type": "POST",
"url": "https://bla.com",
"authProfile": "O"
},
"tenant": "T1",
"credentialTemplateId": "Schema1"
}
Example for credential values :
credentialTemplateId : reference of the credential to issue (optional)
Example Response body:
{
"credential_offer_uri":"openid-credential-offer://",
"request_uid": "uuid"
}
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"
}
request_uid :
is a unique identifier of the verify request
presentation_id : is a unique identifier for a specific outcome of a verification.
Example of status:
CREATED
READ
RESPONSE
SUCCESS
FAILURE
credential/offer/event
Send the confirm for an issued credential
POST /credential/offer/event
Request body:
{
"request_uid": "string",
"status": "string"
}
request_uid :
is a unique identifier of the request that triggered the offer
status:
READ
DOWNLOADED
REJECTED
FAILURE