Skip to main content

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",
    "auth_profile_name": "AUTH1"
  }
}
pd_id : business code of the proof template configured on Dizme Stack.
callback : contains the information about the endpoint that receive the callback. 
type is the Method
url : the endpoint
auth_profile_name : authentication defined on the Dizme Studio
By example PROOF_01 business code


 
Example Response body:
{
  "pd_uri": "openid4vp://",
  "request_uid": "12345-12345-12345"
}


request_uid : the unique identifier of the request 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)

callback object contains information about the receipient of the callback events: type is for

POST  /verifier​/request/multiple-use 
Request body:
{
  "pd_id": "proof01",
  "callback": {
    "type": "POST",
    "url": "https://bla.com",
    "auth_profile_name": "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 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_uid}

Request body:
{
  "status": "string", /* BL_SUCCESS - BL_FAILED */
  "reason": "string",
  "messages": [
    {
      "lang": "string",
      "body": "string",
      "title": "string",
      "mime_type" : "text/plain"
    },
   ],
  "available_actions":[
   {
    "action":"OFFER"
    "data": {
      "offer_uri" : "...."
       }
    }
  ]
}


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.
OFFER - VERIFY - INTENT

status : 

BL_SUCCESS - if the organization confirms a successful verification for credential
 Example for notification status in wallet

BL_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 from the wallet with the data

verify/status

The service allows to retrieve a verify status

GET /verify​/status/{request_uid}

Example Response body:
{
  "request_uid": "string",
  "multipleuse_request_uid": "string",
  "status": "string"
}

multipleuse_request_uid : the unique identifier of the multiple request generated by the system.
request_uid : the unique identifier of the multiple use request already sent or generated by the system.

issue/request (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 generated by the system.
credential_offer_uri : url to be embended into ar qrcode/or to send to the user via other method (sms, email, webpage)

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"
  "multiple_request_uid": "string"
}

request_uid : is a unique identifier of the verify request 
multipleuse_request_uid : the unique identifier of the multiple request generated by the system.

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
Back to top