digeorgi
commented
3 weeks ago Thank you for your input. If we understand correctly, your comment is about a mandatory 1:1 relationship between the Wallet Instance and the WSCA. Indeed the ARF main document refers in the section 4.2 that one WSCA is associated with at most one Wallet Instance. However, this is wrong; it should have read "at least on Wallet Instance. This will be corrected. Moreover, the ARF never said that one Wallet Instance could not be associated with multiple WSCAs. It's perfectly possible for a Wallet Instance to use multiple WSCDs/WSCAs and to store some credential (keys) in one WSCA and other credential (keys) in another one. In particular, one of these WSCAs may run on a remote HSM (being the WSCD), while the other may be a local SAM or Secure Element. We hope this answers your questions.
(The word Credential in the text refers to both PIDs and Attestations.)
(Before anyone would say that this concept is not working or not supported by the ARF consider that this model is simply extending and generalizing the approach when external secure element – ID card - is used to provide PID for the wallet. In such a scenario the ID card is a WSCD/WSCA while all the Attestations are stored in a different WSCA.)
If the mandatory 1:1 relationship between the Wallet Instance and the WSCA was made more flexible, then provisioning of PIDs and Attestations, as well as operation of the wallet could perhaps be simplified. Presently: providers may not be satisfied with the User’s WSCA which may lead to interoperability problems; all WSCDs and WSCAs need a common root certificate otherwise verifying their genuineness will be a real challenge; validity checking of PIDs and Attestations requires unique IDs which can lead to User profiling; Users with multiple devices need duplicate wallets; combined presentation of attestations stored in different wallets is not possible though some use cases would need it.
All these challenges could be solved if Wallet Instances and WSCAs would have n:n relationship.
The Wallet Instance of the User could store PIDs and Attestations in multiple WSCAs and the same WSCA could serve multiple Wallet Instances of the same User.
In this model Users register (authenticate) with their PID and Attestation (=Credential) provider which defines the WSCD and WSCA to be used for their specific credential. This scenario has the following consequences: • WSCDs and WSCAs do not need a common root of trust because each Credential provider uses WSCDs and WSCAs which are certified by their trusted partners. • Having the various Credentials/keys stored in a number of different WSCDs/WSCAs means that a Wallet Instance will be connected with multiple WSCAs. • Being connected to various WSCDs/WSCAs has the result that a single Wallet Instance can achieve full interoperability with any type of Credentials. • If the Wallet Instance is connected to multiple WSCAs it can also combine multiple Credentials stored in diverse WSCAs for a single presentation. • In this model there is nothing which would prevent access to a WSCA by more than one Wallet Instance. Users with multiple devices can use the same WSCAs with each of their Wallet Instances running on the various devices.
If WSCDs/WSCAs are in the cloud, then • Credential providers have access to their related WSCAs and thus are able to remove expired/revoked credentials. Consequently, there is no need for revocation lists. • If there are no revocation lists there is no need for unique Credential IDs which can be used for User profiling. • There is no need for additional back-up as Credentials are securely stored in a decentralized cloud architecture and these Credentials are anyway replicas of the original ones stored by the Credential providers. • Credential providers may even decide whether they want to use HSMs or real physical chip cards (in card farms) as WSCD, the latter making sense if Credentials are presently stored in physical chips (e.g. passport) and Credential Providers do not want to change their operating model or compromise their existing level of security. • As the validity of Credentials is not checked during their presentation their expiration time is to be included upon their generation by the WSCA. The length of the validity period between generation and expiration is defined by the Credential providers. • Cloud WSCD operators of PID providers could also have the additional function of verifying the validity of Wallet Instances which are requesting access to their WSCAs. This function could substitute the validity control to be performed by the Verifiers and thus removing the potential of User profiling by the Relying parties. (In this scenario the Credential presentation data would not need to contain the unique Wallet Instance ID.)
However, to even solve the challenges of offline or battery off transactions the architecture model needs to be extended with local WSCDs/WSCAs (SIM, eSIM, eSE). Wallet Instances potentially will have connections to multiple cloud based WSCDs/WSCAs and only one local WSCD/WSCA.
• Local WSCDs/WSCAs will need a common root of trust because these will support all the various Credentials, and all Credential providers will need to recognize them. It is the simplest to meet this condition with SIMs and eSIMs by regulating the specific requirements for the EU markets. • Local WSCAs will periodically (the frequency to be defined by the Credential providers) synchronize with the cloud WSCAs and will receive time bound copies of the Credentials with expiration periods, just like presented Credentials do. With this approach the validity of Credentials can be guaranteed also in offline transactions without the need for additional verification with some Trusted partners. (Which are anyway out of reach in case of offline transactions.) • As one cloud WSCA may have multiple Wallet Instance connections it may also have multiple local WSCA companions as Wallet Instances and local WSCAs are in 1:1 relation. Users need only one set of Credentials for any of their devices and Wallet Instances, for any type of transactions.
More details can be found at: https://www.safepaysys.com/post/decoupling-the-wallet-instance-from-the-wsca