Add a mechanism for notifying the wallet about certain events

[awoie]

ODI4VCI would benefit from a mechanism that allows issuers to send notifications to the wallet or its backend to enable:

• The ability to notify the wallet of specific credential issuance process-related events, e.g., to reduce polling requests at the deferred issuance endpoint.
• The ability to inform the wallet or its backend about certain risk-related events, e.g., fraud, key compromise.
• The ability to notify the wallet of specific credential lifecycle-related events, e.g., a credential has been revoked independently from the status mechanism and associated TTL windows, new credential types can be requested, or the underlying credential dataset has changed, which is relevant for many credential types such as age-over-18, marriage, etc.

A potential solution could be based on the OIDF Shared Signals and related IETF standards work as presented at IIW. The slides can be found here.

The solution should support both push and pull notification mechanisms. While the pull mechanism is easier to implement, it has certain limitations. For example, if a wallet must maintain relationships with several issuers, polling event endpoints from those issuers introduces a significant load on the mobile device.

[peppelinux]

awesome!

the pull method is pratically what can be achieved using oauth status attestations, because the wallet instance automatically request and obtains the (relevant) updates about the status of its credentials

the push method raises to me some privacy concerns, since the wallet backed would be informed about which credential the wallet instance (holder) has obtained and their status

I'm really excited about your ideas anyway, since I'm wondering as well about how the shared signals may comes into place. In my context they may have sense between the VCI and the authentic sources. When an authentic sources changes the status of the data, previously used by a VCI for the issuance of a credential, the authentic source would signal this change (while the VCI should therefore revoke the credential).

the things I really like is that RISC seems quite ready for the main use cases I have in mind.

[awoie]

awesome!

the pull method is pratically what can be achieved using oauth status attestations, because the wallet instance automatically request and obtains the (relevant) updates about the status of its credentials

Yes, it can be but it would be good have to have a status method independent option even for this use case. Using the status method would require the wallet to poll some endpoint on a regular basis which might be an issue if wallets interact with a lot of issuers.

the push method raises to me some privacy concerns, since the wallet backed would be informed about which credential the wallet instance (holder) has obtained and their status

The idea would be that the event is encrypted to some ephemeral key the wallet holds, so the wallet backend is not aware of what is encoded in the event. There are ways the wallet backend can be implemented without compromising privacy. I agree that there is still a tradeoff but to scale such a solution a push model is still required and imo, it will be implemented anyways. If we can refer to a standard, we could at least give privacy guidance and benefit from all the other great things a standard can give you.

I'm really excited about your ideas anyway, since I'm wondering as well about how the shared signals may comes into place. In my context they may have sense between the VCI and the authentic sources. When an authentic sources changes the status of the data, previously used by a VCI for the issuance of a credential, the authentic source would signal this change (while the VCI should therefore revoke the credential).

the things I really like is that RISC seems quite ready for the main use cases I have in mind.

Yes, something like RISC seems useful. And I believe, if OIDF Shared Signals is used, any SET type can be communicated.

[Sakurann]

in-person WG mtg:

• problem statement sounds reasonable
• next steps are to discuss requirements and specific mechanisms
  • need to discuss if push from issuer to the wallet works only when the wallet has a backend
  • need to discuss if pull from the wallet to the issuer make sense too, given there is notifications endpoint
• @leecam suggested platform might be able to help?
• potentially need to update notifications endpoint with more signals.

[peppelinux]

@awoie

Using the status method would require the wallet to poll some endpoint on a regular basis which might be an issue if wallets interact with a lot of issuers.

Yes, the web operates with hundreds of HTTP requests in less than 1 second. For example, to load the content of this GitHub page, more than 110 HTTP requests were made for various resources like CSS, JS, SVG, etc. It's quite remarkable; that's just how the web functions. Likely, my Wallet won't hold more than 100 credentials, and the status assertions provided by these credentials will probably be preprocessed and stored in their cache, ready to be served as static content.

The idea would be that the event is encrypted to some ephemeral key the wallet holds, so the wallet backend is not aware of what is encoded in the event. There are ways the wallet backend can be implemented without compromising privacy.

Your point is valid; the Wallet Backend could indeed inspect the IPv4 address of the credential issuer (that makes the request), thereby gaining insight into the types of credentials the issuer is capable of issuing. Additionally, despite encryption, the Wallet Backend needs to identify the intended recipient of the payload to ensure it is delivered to the correct wallet instance. This process could inadvertently reveal to the Wallet Backend the types of credentials held by a particular wallet instance (and likely its user), all without the user's explicit consent.

Please accept my apologies for the paranoia, @awoie ; these concerns are among the reasons why I was compelled to create the status attestations, it was not an easy decision.

[Sakurann]

please indicate in the issue if you are interested in implementing a mechanism like this.

[sloops77]

@Sakurann yes we would. we have a custom version of something similar already.

[deshmukhrajvardhan]

@awoie Thanks for creating this discussion topic. The use cases I have seen for the Shared signals framework is to exchange risk signals between companies and product backends.

For Issuer to wallet, we might want to take these considerations:

1. Wallets usually reside on mobile devices (phones) and exposing an https endpoint on them for a push functionality isn't a good idea. We might want to do Websocket or some other protocol that works well with mobile.

2. It might not be reliable for Issuers to send risk signals to the wallet app, I am not sure about what the wallet is supposed to do with that info, extra logic would have to be added to the wallet app to parse the risk signal and take action. In my opinion issuer itself should parse the risk signal and then send a push notification to implement an action e.g. revoke the user credentials.

3. (Update from Shayne Miel) Shared signal supports CAEP (about active application sessions) and RISC (about managed identities in some directory) schemas by default. Okta and Disney have defined a bunch of their own custom event types that get transmitted over SSF, and the SCIM working group has a proposal to use SSF to transmit SCIM events. https://openid.net/specs/openid-sharedsignals-framework-1_0-03.html https://sharedsignals.guide/#eventdefinitions

4. As the wallet will interact with various issuers, in most cases they will need to use 1 receiver per transmitter and will need a secure way to exchange a shared secret between the transmit and receiver pair. In the current interops and PoC's, they have to do it out-of-band and also need to think about secret rotation. Doing this on a large scale is a new problem to tackle.

5. Can you explain more about the wallet backend? I was under the impression that the issuer talks with the wallet directly. What is the nature of the wallet backend?

Here is an open-source implementation of the transmitter and receiver https://github.com/duo-labs/sharedsignals