v2.1.0-beta
✨ New Features
The subject field feature in the Open Payments auth server adds a way for Open Payment clients to simply verify the ownership of a wallet address, without requiring an outgoing payment grant.
For integrators, this concerns the IDP behaviour. Now, when the IDP requests a grant lookup (you can see the updated OpenAPI specs here), instead of (or alongside) the access_token, it's possible to get back a subject field in the following format:
"subject": {
"sub_ids": [
{
"id": "{{walletAddress}}",
"format": "uri"
}
]
}
Here, the IDP must verify that the end user does in fact own the requested wallet address, which means updating the consent screen with the proper verbiage for the user. As an example, in the mock ASE, when the subject is requested, the consent screen presents "{thirdPartyName} is asking you to confirm ownership of {walletAddress} wallet address".
Updating the consent screen, and making the check that the wallet address belongs to the user going through the interaction are the required changes in the IDP. Approve & finish behaviour remains the same.
Behaviour change: Whenever a wallet address is fetched using Open Payments API, we send a wallet_address.not_found webhook in order for the ASE to have an opportunity to create a wallet address "on the fly". Previously, this was enabled by default, and now, this is disabled by default. If you need to enable this, you will need to enable WALLET_ADDRESS_NOT_FOUND_POLLING_ENABLED flag in backend.
🐛 Bug Fixes
Made sure that during hash generating in the auth server, we use the full grant URL/auth server URL along with the tenantId.
🔧 Chores
Full Changelog: v2.0.0-beta...v2.1.0-beta