Set up the verifier
In EDK the tenant runs the OID4VP verifiers that onboarding created; the verifier service lists them and reads one, but does not create or delete them. Setting one up means finding it, reading and updating its client settings, and giving it a verifier design, so wallets see who is asking.
Complete first: Onboard a tenant, Connect Azure KMS with BYOK and BYOC.
Steps and why they come in this order
| Step | Why here |
|---|---|
| 1. List your verifiers | Open on what already exists: every verifier the tenant runs, with its id, status and public endpoints, before one is changed. |
| 2. Read the verifier client settings | Onboarding wrote defaults. Read them first so an update changes only the fields you intend. |
| 3. Set the verifier identity and endpoints | Wallets see the name and send responses to the URI in every request, so settle them before any request is created. |
| 4. Give the verifier a design | A verifier design is how the relying party is presented to holders. Verification templates can reference it, so it comes before them. |
What the API does and does not cover
The verifier service lists the tenant's verifiers and reads one (/api/oid4vp/v1/instances); the tenant is
taken from the access token. Creating, updating and deleting verifier instances is not part of EDK:
the tenant gets its verifier when onboarding runs with the verifier capability. Its settings are Platform Config resources under
/api/platform/config/v1/tenants/{tenantId}/oid4vp/verifier/..., and its presentation to wallets is a
verifier design in the credential-design API.
Deeper reference
Verify credentials maps the Admin Console verifier
screens (surface=verifier). Credential design REST API
describes the shared issuer and verifier design contract.
Next journey
Continue with Adjust the verifier configuration.