openid
First Class Server-to-Server support in VCI (requirements)
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.
this is a great start, thank you. Few questions..
- what about user authentication? ie how does the issuer know which user's credential is being issued? does the user authentication information collected on the mobile device (ie ID card screenshot) or via desktop browser is being passed to the issuer via the wallet server or directly to the issuer?
- is there a need to support "issuer-initiated" and "wallet-initiated"? or it does not matter?
- what does it mean that
the Issuer should be able to verify the origin component (for encrypted information)? What is origin in this context?
Additional topics from the IIW session on day 3
Device Migration
- Old device present
- Old device not-present (requires registration of a backup key)
Companion Devices There was lots of discussion on how this is very similar to the old device present flow.
Multi credential issuance This means credentials
- With different types/doctypes
- Of different lifecycles
- Of different formats
- Same issuer
- Same user
- Same authentication/proofing process
User Authentication/Proofing
- Inband
- Out of band
- How evidence is provided
Notifications
- Issuer to Wallet
- Wallet to Issuer
Identifiers in protocol
- Device
- User
- Credential
- Version
Authentication
- Wallet to Issuer
- Issuer to Wallet
Encryption Encrypting to wallet device through to issuer.
post IIW DCP WG notes discussion points for today:
- understanding requirements/assumptions for server-to-server
- agree on the building blocks
notes:
- difference in uptime btw wallet instance, issuer, wallet server (in the ascending order)
- none of this new work should complicate existing VCI implementation
- will start a gdoc
Building blocks
- issuer authenticating the user (like selfie, picture of a plastic card, etc)
- authorization of the wallet server to the issuer server (something like mTLS etc)
- issuer server establishing how to determine information is coming from user device
- user authorization bound to the key on the user device
- wallet/credential lifecycle management, now that issuer can push to wallet server (some of these features might apply to VCI too)
continued documenting overall flow in a sequence diagram - not meant to be deterministic but rather to improve understanding of the big building blocks
please use this Google Doc as one place to collect the requirements and discuss/agree on them: https://docs.google.com/document/d/1spjhNkVqTd2E9dDrH7YSNz9xgl6wwdOhS5C9yW29ArE/edit
Note: The document has been updated with a Prospective building blocks needed to meet these requirements and some sketch solutions. PTAL.