Wallet must protect itself against unwanted offers

[reinkrul]

Although this is a more involved problem in a server-to-server flow (since there's no user to accept the VC into the wallet), the least it should do is filter credential offers for credentials it wants. This should be a configurable list.

For now, it should accept NutsAuthorizationCredential by default.

It should also handle all of the offers (if applicable), instead of just one.

[woutslakhorst]

Accept all credentials requires no config and supports all future use cases. But this would enable credential spamming by untrusted issuers. The type of credential is not the problem here.

Any network participant could spam any other participant. There are two approaches to solve this problem: prevent or fix. Prevention focusses on not accepting offers from certain parties. Fixing focusses on blocking and deleting after the fact. Prevention is done by using an allowlist based on:

• manually added DID/type combo's
• allowing DIDs based on attestations In all cases this would not block a node that started out nicely and then starts to spam. A fix is always needed. So let's focus on the fix first.

Detection:

• warnings in logs when a lot of VCs are offered
• statistics on VCs per issuer/subject/type
• rules per type for the above two rules

Fix:

• block spammer via firewall (x509 based)
• delete VCs based on params

[woutslakhorst]

"Normally" Detect "disk full" (>80%) -> investigate large tables -> "select count(id) from X group by issuer having count(id) > Y" -> investigate contents -> block or "delete from X where issuer = Z"

This is a lot of effort with the current key/value storage....

proposal: convert storage to SQL first, then done....

[reinkrul]

Server-to-server OpenID4VCI implementation will be replaced with OAuth2 s2s/OpenID4VP-flow with policy backend, removing the need for Nuts Authorization Credentials, thus removing the need for this feature.