...
Table of Contents
1. Introduction
1.1 Audit events in the future
2. Integration Steps
2.1. Send us required information
2.2. Validate subscription
2.3. Receive audit events
...
By utilizing Cloudevents delivered to a Webhook over HTTPS, we adhere to standard protocols decoupled from specific libraries or SDKs. In this guide, we aim to provide you with the necessary information to set up a receiver capable of receiving audit events from our systems.
1.1 Audit events in the future
While the current integration only send audit events related to password reset, this will likely be expanded in the future with new messages. Some example use-cases for sending out audit events are;
- App activation as OTP
- Automatic block of BankID certificate based on anti-fraud signals
- Biometric activation
2. Integration Steps
2.1. Send us required information
...
Two main things to note about the payload are the type and data fields.
3.1 Types
Type will have one of two values:
no.bankid.bass.audit.reissue.init.v1 Used for events sent right before the reissue command is sent. This signals the intent that the user will now perform a password reset, and the user can no longer abort.
no.bankid.bass.audit.reissue.completed.v1 Used for events sent right after the reissue command is sent. This signals that the command has been sent, and will specify if the command was successful or failed.
3.2 Data fields
Data will be a json with the following specification;
| Parameter | Type | Possible values | Sample data | Description | Required |
|---|---|---|---|---|---|
| sessionid | String | 7468bdd3-274b-4e2f-b7bb-65dad59ce8a9 | SessionID of the transaction. Is only valid for a single password reset. | Yes | |
| authentication | String | BIM | BIM | Authentication method used to identify the user | Yes |
| action | String | REISSUE | REISSUE | Actual operation | Yes |
| orderid | String | 1012-1667319077298 | OrderID of the BankID | Yes | |
| time | String | 2022-10-26T14:15:51.978Z | Execution timestamp(ISO8601) of the reissue command. Not set for events with status=BEGIN | No | |
| status | String | BEGIN, SUCCESS, FAILURE | SUCCESS | Status of the transaction. | Yes |
| additionalInfo | String | Details information if applicable to action, like error message in case of failure | No |
3.3 Handle incorrect messages
While the messages are defined, typos and errors may occur on either end. As such, you need to have proper handling of errors related to the messages - such as, but not limited to, unknown type, unknown data fields, missing data fields, unknown data values etc.
If you discover incorrect messages, contact us for troubleshooting. Please include the full message and time of delivery.
4. Security
4.1. Webhook URL
...