1 of 9

OID4VCI Events

Oliver Terbu @awoie

https://mattr.global

2 of 9

Use cases

  • Notify the wallet in case the credential got revoked before end of TTL window.
  • Notify the wallet in case a new credential type can be requested.
  • Notify the wallet the data for one credential got updated and a new credential with the updated data is available.
  • …

3 of 9

Use cases (conference)

  • Risk-based events (e.g. fraud, security compromises etc.), lifecycle management-related events (new version is available, updates to data e.g. age-over-18)
  • In certain Wallet backend vs wallet instance
  • Ability to notify the wallet when it is time to poll the deferred issuance endpoint again.

​

4 of 9

5 of 9

Proposals

  • Option 1: Use IETF Security Event Token (SET) Delivery
    • RFC8417: Security Event Token (SET)
    • RFC8936: Poll-Based Security Event Token (SET) Delivery Using HTTP
    • RFC8935: Push-Based Security Event Token (SET) Delivery Using HTTP
  • Option 2: OIDF Shared Signals
    • Based on top of Option 1
    • Question: added benefit of Shared Signals? Can it be reused?
  • Option 3: Extend notification endpoint
    • Existing spec defines how to send notifications from the wallet to the issuer, not the opposite way.
    • Not a real option → does not support issuer to wallet notifications

6 of 9

Option 1: PULL mode

  • Based on RFC8417, RFC8936
    • Don’t define request/response structures or endpoints
  • OID4VCI issuer exposes an endpoint for event queue and included in OID4VCI issuer metadata.
  • Endpoint is another resource endpoint protected by OAuth, i.e. OID4VCI access token.
  • Questions
    • Specific to wallet instance, or credential instance, or both?
    • Event endpoint in OID4VCI issuer metadata?

7 of 9

Option 1: PUSH mode

  • Based on RFC8417, RFC8935
    • Don’t define request/response structures or endpoints
  • Wallet backend endpoint exposes an endpoint for pushing events.
  • Request/response structure end endpoint has to be defined.
  • Interaction between wallet and wallet backend is out-of-scope
  • Challenges
    • How to protect the wallet backend endpoint?
    • Hide issuer/wallet instance relationship from wallet backend, especially when using Push Notifications.
  • More complex than PULL but we probably need both modes
    • Polling is expensive if wallets have relationships with a lot of issuers

8 of 9

Option 2: OIDF Shared signals

  • OIDF Shared Signals ID-2
    • Supports PUSH and PULL mode
    • Allows sending of IETF Security Events
    • Profile of IETF SET and IETF SET Delivery Methods
  • Defines well-known for SSF configuration
  • Defines request/response structures
  • Defines endpoints
  • Discuss
    • Would it make sense to reuse OIDF shared signals and define a new profile for SET for OID4VCI events?
    • PUSH endpoint protection uses static authorization header which might not be great, e.g., does not support DPoP?

9 of 9

Next steps

  • OIDF Shared Signals ID-2 is probably the best approach
    • Present proposal to OIDF Shared Signals WG
    • Solve issues on PUSH endpoint authorization, e.g. using IETF HTTP Signatures
  • Whitepaper required will be worked on in parallel (potentially by OIDF)