Replies: 4 comments 9 replies
-
|
To break the ice, I'll post the same topic I suggested on the Architecture SIG call: in my experience, the most foundational component of a digital wallet architecture is the key management system (KMS). Pretty much everything else depends on it. So the proposed high-priority topic is: does the OWF engine need to have a standard KMS module — or at least a standard KMS interface — for all the key management operations that other components will need to call? And if so, can we agree on a common set of requirements for this KMS? |
Beta Was this translation helpful? Give feedback.
-
|
I agree @talltree ; i would be keen in participating topics such as KMS isolation, standard comms, look at old PKI API standards (i.e KMIP, PKCS) to take lessons from and adapt to new cryptography, the different strategies depending on the run-time environments, TEE vs no-TEE support, etc. I created a topic for discussion too about this but don't know if it's the right place: #49 I'm open to bring my exp and contribute as well. |
Beta Was this translation helpful? Give feedback.
-
|
@OR13 had drafted this class diagram on key management services when we were first discussing. It would be great to get your thoughts on this. |
Beta Was this translation helpful? Give feedback.
-
|
Yep, key and credential management. In many cases you will need KMS to decrypt credentials and to present them if they have a "holder binding". The interfaces and capabilities of KMS systems vary on desktop, mobile, web and server wallets. |
Beta Was this translation helpful? Give feedback.
-
|
I assume the basics of KMS, secure storage, access management, etc. are taken care of. The architectural need that I see missing most relates to sharing of information that is managed and stored. For clarity, I mean at the OS-level. Currently, there is very minimal inter-app sharing on a device. This forces many applications to implement their own wallets. This means that while the wallets may be open, even OWF-based, they can't talk to each other and now you have both terrible UX AND propagation of mistakes in implementations. There are solutions to the cross-app sharing but they are clunky and not likely to be consistent. I fear that the OS providers (Apple, Google/Android, etc.) may resist this idea, but I think there are real business benefits to creating a common layer that handles the key management, secure storage, and access. Without the buy-in from the OS providers, we're somewhat hamstrung.
|
Beta Was this translation helpful? Give feedback.
-
|
I understand the intent; but it's not clear how to achieve this and such a design doesn't separate the application (wallet) from a raw / traditional KMS. "Key Management System (enclave/TEE"; that's would be the best scenario for in-memory operation; but the reality is that TEE's/Enclave ship with only vetted / pre-compiled code by the manufacturer. If you need specific crypto like ed25519 / BLS-381 / secp256k1; it will not provide that for you and you cannot add your own functionality to it. So where will you run your own KMS? We can rely on the enclaves / TEEs for encryption at rest, but because of requirements such as the ones described above; you will have to have security model / isolation strategy that guarantees separation between your application (a.k.a "wallet") and the actual KMS that will need to have it's own run-time space to handle key material and crypto operations without being exposed to regular application space. Meaning, Trusted vs Untrusted space needs to be clearly defined imo. With isolation then we get into the communication aspect of it, and imo, a good exercise would be to revisit existing PKI API standards that already try to abstract KMS / HSM / Enclave interactions; such as KMIP ou PKCS#8/#11 and learn from that. Maybe we can use or re-use those to come up with something that can support more modern cryptography. |
Beta Was this translation helpful? Give feedback.
-
|
From our call today perhaps this scribble helps explain the three body problem I am trying to explain: |
Beta Was this translation helpful? Give feedback.
-
|
I'm sure we all want "secure treatment", "secure storage" or "access management"; The real question is WHY is it secure? And HOW are we going to achieve it depending of WHERE we are running it? |
Beta Was this translation helpful? Give feedback.
-
|
I agree with TallTree and Enoc re: the importance of KMS and the necessary separation of its implementation from enclave/TEE, and a Trusted space within which it runs. Separate from that the mechanism for securely exchanging wallet contents with others seems a core feature, yet one that hasn't reached consensus on wrt implementation methods. Currently in the W3C_VCDM world the use of Verifiable Presentations is the most common approach, but that is currently limited to payloads that are credentials. There is an issue in the current VCDM v2.0 wg to expand what payload types might be enclosed in a VP and still be compliant with that ecosystem. In short a second critical topic is the approach by which wallet contents are exchanged with third-parties. This may be something considered out of scope for the wallet architecture itself, but is remains of central importance to address. |
Beta Was this translation helpful? Give feedback.
-
|
List of exchange protocols for verifiable credentials (discussed in the June 12, 2023 Architecture SIG call):
Need to determine similar lists for payments and objects. |
Beta Was this translation helpful? Give feedback.
-
+1We are particularly interested in this area as our ambition is to put in an OWF project proposal for an open source project for our three Core API Services Adaptors. This is part of our commitment to interoperability and use of Open source in our Platforms. We intend to benefit ourselves from creating an easy to use, safe, well maintained set of plug and play adaptors for our core APIs as a package that can be integrated into the appropriate package build and inclusion process supported. What Mydex CIC APIs do the Adaptors Connect to?
Our Core API subscribers perform different roles in different contexts. They may be a
Verified Credentials (Attributes | Proofs of claim)All verified credentials are stored in the Members independent PDS - These are currently in several different formats as we are operating across different ecosystems and clusters (Public Services delivered by local authorities, social care, independent care sector and third sector with different platforms and data standards (often not well documented. This is core problem we solve through our interoperability layer in our PDX API. We see this as one of the key challenges that we will need to continue to be worked on one brick in the wall at a time until we build up momentum. This going to be the case for sometime to come (15 to 30 years). we Store in a range of ways
The current approach is 80% of the FERC of a person life, the focus on getting people onboarded and verified I understand but it is a transitionary step, the main opportunity of getting OWF right is the ability to scale our the economy whether for profit or to improve public services in a way that enables data to come together in new ways. New ways that drive innovation and the ability for people to join the dots of their own life and be an active . Interoperability is at the heart of adoption because the world and specific sectors are in different places and different priorities that need mapping into on a path to interoperability first and that will take a community effort to achieve as ever because no one community, scheme, organisation or state can do this without Open Source code base.
Why make our Adaptors Open SourceAdoption, Assured Access, removal of barriers, ease process of integration. Wanting to ensure as a CIC we avoid the risk of anyone getting trapped in pseudo open source adapters following risk of changes of policy by commercial organisation who started it all but kept the IP to themselves and used the open source code marketing message but then changed their minds. That lack of true open source project with the right charter and governance prevents that to a large extent and turns it into the wonderful debate the comes from diverse perspectives and use case. We have found the pseudo open source offer but on commercial terms means this space can get uncomfortable unless projects and programmes like OWF do not exist to keep the door open to the community.
We want to support this as the primary initiative to deliver an integration layer between our Cloud based Personal Data Store and Wallet and our plans for a hybrid Wallet Model . We want people to be able create trust relationships between the Wallet and device and their Cloud Wallet and PDS. What data we carry across our platformsWe carry a wide range of data payloads for our Members (People) who as a CIC we serve without out bias or agenda. We ask nothing for the use of the tools we have created for them to manage their whole life. Critically it is their ability to plug into their and our our subscribers using our APIs that we are keen to make fully open source. This will be the source we pull into our own Web Based Experience Layer to deliver the integration to the Core Services API functionality that will support and synch with ours and any other OWF open source Wallet Experience layer for Cloud and Device based wallet functionality they will need to participate and a node on multi scheme and networks as a point of integration and control. The PDS is the cloud based store of their lifetime, events, transactions, life events and related transactions and life stages, periods of transation and change. Who We Work withThe majority of people we work with are vulnerbale out of work on suffering in work poverty with a diverse range health and socially related challenges they need help with. We provide a means of connecting and recuctions in the Friction Effort, Risk and Costs People and Front Line teams experience in delivering operational end to end service. Geeting through the front door and giving consent to data sharing either dynamically via a wallet based minting of any access token or more detailed GDPR compliant data sharing agreement to supports ongoimg operational engagement and data exchange set out in the DSA which the individual can review and adjust within the parameters of operational service delivery. We fully expect our Members to need to interact with multiple ecosystems using different protocols and working under different trust frameworks and schemes certified under them. Our goal is driven by a human rights and person centred approach which places them at the centre of their life with control, agency and guardian ship capability including data sharing agreements (Information sharing agreements | Smart Contracts | The rules) of a relationship between two parties. This empowerment element is core to our architecture and model. We want to support as much diversity of Wallet Providers able to connect their Wallet to our Members Personal Data Store and through our integration API create a trusted relationship and data synchronisation, portability, and back up between the third party wallet operated either by an individual independently or a Wallet Service Provider provider as well as those Wallets bound to a specific organisation centric notion of Personal Empowerment and control Wallet implementations as part of some control surface that only works inside a walled guardian and means of participation in a Scheme. These wallets are not independent from the Organisation or Scheme. We see a world where People can choose the Wallet of preference like they choose an Authenticator App to support mandated requirements of service providers or their own personal preferences about being able to use their personal data Independently of that Wallet or its contents |
Beta Was this translation helpful? Give feedback.
-
|
Authentication to the wallet is up there. Ensuring that only the authorized holder of the credentials and keys maintained by the wallet can access or share them should not be discounted. Relying on native, edge authentication mechanisms may be suitable for some use cases but not all. |
Beta Was this translation helpful? Give feedback.
-
|
We are particulary interested in trust binding between a device based wallet and cloud based wallet which is underpinned by a Personal Data Store independently controlled by the Individual. They will need to operate across different schemes and sadly different wallets if walled gardens even if OWF based but inside a certiication boundry for its implementation. Making the indiviual and their lifelong store of personal data verified credentials of course but also fine grainded transactions from credentialed sources across all aspects of their lives. Not the sort of stuff you carry around in your wallet, you willonly have a subset in the wallet to meet operational needs offline as well as on for everday living. The Cloud Wallet and PDS is managing the always on 24 x 7 API engine for policy based lights out processing under a data sharing agreement minted by the individual unique to the subscriber or as part of a response to a Wallet Control surface request to release specific data dynamically that is not stored on the device but visible, selectable and shareable via the Cloud API or usig the Device wallet as a proxy. WE see in the current climate a plethora of wallets and devices needing to be authenticated and bound to our Members Cloud based Wallet and Personal Data Store to create a web of trust across deices and contexts. This gets a plus 1 from me |
Beta Was this translation helpful? Give feedback.
-
In the 2023-04-03 Architecture SIG call, we brainstormed a set of digital wallet engine architecture topics. What do you think is the MOST important wallet engine architecture topic (or small set of inter-related topics — no more than 3) that the Architecture SIG should be tackling first? Please feel free to include an item that is not in the brainstorm document.
Beta Was this translation helpful? Give feedback.
All reactions