First Class Server-to-Server support in VCI (requirements) #663
Description
This is an attempt to describe the general requirements and reasons as to why someone might want an architecture of a Wallet that contains both a server component and a client component. This is attempting to be a framing for these conversations rather than a
Requirements:
The protocol should support a secure, scalable and easily deployed installation of a server to server architecture.
- The server component should only have access to information that is needed, preserving user confidentiality and taking a data minimization approach.
- The Issuer should be able to verify the origin component (for encrypted information)
- Be able to perform lifecycle management to/from the issuer (e.g. issuer -> server pushes, server -> issuer request/polls, credential revocation/deletion/suspension, device transfer?)
- Be able to perform proofing / authorization through server
- Potentially providing additional server signals to this process to compliment the client ones
- The protocol should support easy deployment and scalability of a server to server installation
- Avoid unnecessary round trips of information through the client to reach the server (for performance and reliability) e.g. support delivering context information by the server together with the encrypted credential package
- Multi-party encryption, e.g. encrypt one part of the information to the server and another part to the device, or encrypt to different parts on the device.
- Support multi-doc issuance, i.e. multiple documents that belong together but are separate documents
Why?
While this split architecture adds complexity, it provides a number of potential benefits.
Reliability/Maintenance:
- Version Skew: Apps updates can not be deployed quickly, and the tail of users on older versions is quite long. This can allow deploying of fixes to old versions, as well as mitigate security and experience issues to all users.
- Monitoring/Alerting: Detection of issues introduced by either the Wallet or an Issuer. Such alerting can be done more quickly and more reliably from a server.
- Polling/Notifications: Easier to perform reliably from a server, and to detect bad states.
- Uptime/Availability: Can allow the Wallet Server to assist the Issuer in uptime/availability.
Security:
- Servers are a controlled environment, making them more secure for some operations (e.g. Risk signal processing, ATO detection etc).
Privacy:
- In some cases, direct interaction between a user’s device and an issuer server may allow the issuer to fingerprint the device which could be a breach in privacy.
Note: Many of these can be performed by an Issuer Server, so the benefits of this architecture is primarily when Wallet != Issuer, and Issuers wish to be able to offload some of this responsibility to the Wallet Provider.
Strawperson Architecture
At a high level, server-to-server architectures tend to work as follows:
- Establish a public key with the issuer server
- Perform authorization, ensuring at least some of which is bound to the public key and not visible by the server component (once authorized)
- Perform signed (+encrypted) credential requests and responses via server
- Perform lifecycle management through server side polls + notifications
Other Design Considerations
Many of these are applicable to non-server architecture but are important to consider when creating support.
- No browser-centric requirements (this is effectively automatically the case, since a server-to-server interaction will not be browser based)
- Extensible to companion devices (e.g. split in entity that does proofing vs receiving the credentials)
- Support providing proofing evidence asynchronously / through a separate channel / out-of-band (while maintaining security and privacy guarantees)
- Support both in-band and out-of-band capability information, e.g. wallet and issuer capabilities.