How to create and use a Webhook
MATTR VII Webhooks enable retrieving information that is generated during an API interaction but is not included in the request or response payloads.
Prerequisites
- A configured MATTR VII workflow that utilises a supported Webhook event type:
Overview
Creating and using a Webhook hook comprises the following steps:
Create a MATTR VII Webhook
Request
Make a request of the following structure to create a Webhook:
POST /v1/webhooks
Request body
{
"events": ["OpenIdCredentialIssued"],
"url": "https://example.com"
}
events
: This array includes the event types that will trigger this Webhook. Currently allowed types:OpenIdCredentialIssued
: Triggered upon completion of an OpenID4VCI workflow.OpenIdCredentialIssuedSummary
: Triggered upon completion of an OpenID4VCI workflow but only provides a summary of the issuance event, leaving out the credential object.OidcIssuerCredentialIssued
: Triggered upon completion of an OIDC Bridge issuance flow.
url
: This is the URL that will receive the Webhook events data payload when they are triggered by MATTR VII for the specified events:- Must be a valid URL.
- Must use the HTTPS protocol.
- Must not be an IP address.
- Must not include query parameters or fragments.
- Non-ASCII characters are normalised.
- Must return a 2xx response, otherwise it will go through a retry cycle and eventually fail.
Response
{
"id": "0c099611-19c4-4f29-8724-6b9e5ba1ef7c",
"events": ["OpenIdCredentialIssued"],
"url": "https://example.com",
"disabled": false
}
id
: Unique identifier for the created Webhook. You will need it to verify Webhook events.disabled
: Set tofalse
by default, indicating the Webhook is active. When set totrue
the Webhook is disabled and no events are triggered and sent to the definedurl
. You can disable an active Webhook by making an update request.
Verify Webhook requests
MATTR strongly encourages verifying each Webhook request:
- Compare the Webhook
id
that is generated when creating a MATTR VII Webhook with thewebhookId
specified in the event payload. - Verify the request HTTP signature.
Verifying HTTP signatures
All MATTR VII Webhook requests are signed using HTTP Message Signatures (an IETF draft standard). You can retrieve the public keys MATTR VII uses to sign the HTTP and use them to verify the HTTP signature.
Request
Make the following request to retrieve the public keys:
GET /v1/webhooks/jwks
This endpoint is publicly available by design and does not require authentication.
Response
{
"keys": [
{
"kty": "OKP",
"crv": "Ed25519",
"kid": "1608085995",
"x": "1NYsB58B9bNmReXqyQR8R_DeJtoLHSW-JsyZVmV2EWQ"
}
]
}
kid
: Use this key to identify which key a particular HTTP request is signed with.You can cache the response as these public keys are not expected to change often.
Verification implementations
- To facilitate verification of MATTR VII Webhook request, we provide a typescript based library that can be used for verification or serve as a reference implementation to develop a verification SDK in another programming language.
- An
open-source example
of using the
@mattrglobal/http-signatures
library is also available. - To learn more about verifying our Webhook requests, have a look at the Open Source MATTR Http-Signatures library.
Use Webhook events payload
The event payload has a common structure in JSON format:
{
"deliveryId": "9a8b0b72-5c4f-4925-b101-528edbb5d75d",
"deliveryTimestamp": "2022-08-30T01:26:38.325Z",
"webhookId": "5be4f663-af93-41d8-8542-f5c9a2a2d588",
"event": {
"id": "de347800-d56f-4262-9f19-52b34856a933",
"type": "OpenIdCredentialIssued",
"payload": "{event payload}",
"timestamp": "2022-08-30T01:26:38.308Z"
}
}
-
deliveryId
: The unique identifier assigned each time the event is delivered to a Webhook endpoint. -
deliveryTimestamp
: The time when the event was delivered. -
webhookId
: The unique Webhook identifier returned in the response during its creation. -
event
: Includes the following event details:id
: Unique event identifier.type
: EitherOpenIdCredentialIssued
,OpenIdCredentialIssuedSummary
orOidcIssuerCredentialIssued
.payload
: Contains the specific event data. Refer to Event payloads below for examples.timestamp
: Specifies the date/time when the event was created.
When a Webhook event is sent from MATTR VII,
x-mattr-webhook-id
andx-mattr-event-type
are added as request headers.MATTR VII does not guarantee the delivery of events in the exact order that they are generated or that no duplicate events will be received by the Webhook endpoint. You can safeguard against duplicates by checking the
event.id
that is provided in the event payload, this is a unique identifier for each event generated by MATTR VII. Alternatively, make your event processing idempotent.
Timeout and retry
When a Webhook fails to send data to the configured url
, or when a session timeout occurs, a
maximum of three retry attempts are made at set intervals. The interval time increases exponentially
according to the number of retries that have been attempted. If the Webhook fails to send following
the retry attempts, it will be marked as failed.
By default, the Webhook has a response timeout of three seconds. If the server receiving the Webhook event does not respond within this period it is considered a failure.
Event payload
Below are examples of event payloads:
CWT credentials
{
"format": "cwt",
"userId": "7382276d-ef75-4d17-8fb0-1d3aec4647ab",
"credentialProfile": "compact",
"credentialConfigurationId": "1d8c7ad7-84ce-4519-8365-7af986e4ee0e",
"credentialId": "9613ac5e-a0ba-4512-ba0b-90e91b2744bc",
"userClaims": {
"Name": "John"
},
"credential": "{base64url_encoded_credential}"
}
format
: Issued credential format (For CWT Credentials this would always becwt
).userId
Unique identifier of the user the credential was issued to on the MATTR VII tenant.credentialProfile
: Issued credential profile (For CWT credentials this would always becompact
).credentialConfigurationId
: Unique identifier of the Credential configuration that was used to issue the credential.credentialId
: Unique identifier of the issued credential on the MATTR VII tenant.userClaims
: Claims that were collected for this user as part of the issuance workflow and persisted on the MATTR VII tenant.credential
: Base64 encoded byte[] of the issued CWT credential.
JSON credentials
{
"format": "ldp_vc",
"userId": "64a39a9d-c15b-4c78-9149-30f6376f1fbc",
"credentialProfile": "web-semantic",
"credentialConfigurationId": "bddb2a96-8b67-439a-b5af-2818bcfc716f",
"credentialId": "9613ac5e-a0ba-4512-ba0b-90e91b2744bc",
"userClaims": {
"Name": "John"
},
"credential": {
"type": ["VerifiableCredential", "ExampleCredential"]
//... rest of credential data
}
}
format
: Issued credential format (For JSON credentials this would always beldp_vc
).userId
Unique identifier of the user the credential was issued to on the MATTR VII tenant.credentialProfile
: Issued credential profile (For JSON credentials this would always beweb-semantic
).credentialConfigurationId
: Unique identifier of the Credential configuration that was used to issue the credential.credentialId
: Unique identifier of the issued credential on the MATTR VII tenant.userClaims
: Claims that were collected for this user as part of the issuance workflow and persisted on the MATTR VII tenant.credential
: Signed credential data.
mDocs
{
"format": "mso_mdoc",
"userId": "7382276d-ef75-4d17-8fb0-1d3aec4647ab",
"credentialProfile": "mobile",
"credentialConfigurationId": "1d8c7ad7-84ce-4519-8365-7af986e4ee0e",
"credentialId": "9613ac5e-a0ba-4512-ba0b-90e91b2744bc",
"userClaims": {
"Name": "John"
},
"credential": "{base64url_encoded_credential}"
}
format
: Issued credential format (For mDocs this would always bemso_mdoc
).userId
Unique identifier of the user the credential was issued to on the MATTR VII tenant.credentialProfile
: Issued credential profile (For mDocs this would always bemobile
).credentialConfigurationId
: Unique identifier of the Credential configuration that was used to issue the credential.credentialId
: Unique identifier of the issued credential on the MATTR VII tenant.userClaims
: Claims that were collected for this user as part of the issuance workflow and persisted on the MATTR VII tenant.credential
: Base64 encoded byte[] of the issued mDoc.
MATTR VII does not guarantee the delivery of events in the exact order that they are generated or that no duplicate events will be received by the Webhook endpoint. You can safeguard against duplicates by checking the deliveryId
. Alternatively, make your event processing idempotent.