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

[awoie]

@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.

I agree that mobile devices cannot really expose an HTTPS endpoint but a wallet backend could. The challenge is to make this privacy preserving "enough" and this can be discussed what options we have available.

Regarding WebSockets, I'm not convinced that this will be a better solution but certainly a solution we should discuss. I'm concerned about the followoing: connection management (managing loads of open websockets of wallets), statefulness (retaining information about each open connection), battery lifetime and data usage of mobile devices and reconnection handling.

IMO, pull/polling will have to stay the fallback, WebSockets could be explored but I'm concerned about the points raised above. Having a wallet backend/notification endpoint chosen by the wallet can help mitigating these concerns but raise certain privacy challenges we would need to consider.

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.

The examples on risk signals was related to wallet providers. IMO, throughout the wallet lifecycle, there might be signals where the recipient is the wallet instance and some where the recipient is the wallet provider. These signals could be encrypted to different keys to solve that issue, or two separate notification mechanisms could be provided for different types of signals.

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

I would be supportive to adopt the Shared signals work. We would need to identify where the gaps are. Currently, we have a very high-level conversation. Once we have nailed down the use cases, it will be easier to identify what the gaps in Shared signals are.

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.

Agreed, we would need to do some thinking.

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?

I think this depends on the role the wallet provider plays. One example that comes to mind is as follows: a user intentionally misuses a credential and commits fraud. The issuer detects this and wants to enforce deletion. In that case, the issuer might notify the wallet provider to initiate the deletion process. The wallet provider can then help the issuer contain the damage.

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

Awesome, thanks.

[cre8]

a user intentionally misuses a credential and commits fraud. The issuer detects this and wants to enforce deletion

For this the Issuer should add a status management to the credential (CRL, status list, etc) to revoke it. This is the most effective way for this scenario.

We got feedback from some use cases where the credential creation process can take some time (like days). For this it would be great that the process can be delayed. Going first with OID4VP and then later doing a pre authorized code flow seems a bit "dirty".

Maybe the wallet can pass some information in the credential request to inform the issuer that it can use a notification endpoint like the wallet backend to notify when the credential is ready. If this is not supported by the issuer or the wallet is not sending it, it can go via the pull approach of the deferred credential endpoint. While polling is easy to implement, it will only work when the app is in foreground. So a push notification mechanism is the preferred way from an iOS or Android perspective.

The credential can be encrypted, but it still has the privacy problems that a wallet backend knows which wallet is getting credentials (from the sender it only receives the IP address, but no identity of the issuer). The wallet needs to pass some kind of secret in the credential request the issuer can then use to authenticate against the issuer and route it to the correct wallet.