reinkrul
commented
1 year ago As long as the other side is a Nuts node, we can most probably skip retrying at all and return an error if the credential could not be retrieved, as long as the issuing node retries offering the credential. Reasoning:
- The holder not being able to retrieve the credential when receiving an offer is only possible due to misconfiguration (it's unlikely the Nuts node goes down between offering the VC and the holder retrieving it)
- The issuer will have to retry offering when the holder replies with a non-OK status
- When implementing SIOP the issuer and wallet will need retry capabilities, but then we'll have a more clear understanding what we actually need.
We should probably have the wallet respond with a more specific response than specified: the OpenID4VCI spec states issuer expects no response (we implemented it as 202 - Accepted with OK); because if the wallet is misconfigured (e.g. leading to a static HTML page) the issuer currently assumes the offer was delivered successfully, while it wasn't. Then the VC issuance doesn't fallback to issuance over the Nuts network, and the VC will never be received by the holder.
Since the pre-authorized flow will probably be replaced by the auth code flow (and probably not be used by any other issuer/wallet other than the Nuts node), the trade-off introducing an out-of-spec response for the credential offer and checking it on the issuer side, it probably worth it.
So for now:
- Wallet will synchronously retrieve credentials when receiving an offer
- It will respond with a JSON status, indicating the credential was retrieved:
{"status": "credential_retrieved"}. The issuer will check this status; if it receives anything else (e.g. an error) it will fallback to issuance over the network - We'll add the custom response to the Nuts OpenID4VCI RFC
woutslakhorst
Accept credential offers and store them in a persistent store so they can be retried.
Probably needs fields like: