Architecture whitepaper #66
Conversation
|
Excellent document at first review. My only observations is to strengthen the message is that it is implementation independent so things like wholly based cloud wallets are in scope and any number of other form factors we don't even know about yet but will come e.g. embedded in a car, a physical thing that is a cloud wallet not on a mobile etc. |
There was a problem hiding this comment.
Thanks Tracy for that explicit document! Here my comments on device bound credentials, the verifiable data registry and the trust registry.
First point, from my point of view, governmental identity credentials will rely heavily on device bound credentials and I would propose to describe the case of device bound credentials or proof of ownerships.
Second point, I'm missing the definition of a verifiable data registry and a clear separation between the duties of a VDR and a trust registry. There are a lot of different interpretations who should do what and it would be importance to describe it.
For example for me, a VDR should be there to enable the verification of the identity of an public ecosystem actor but should also host the status of issued credentials to create a functional ecosystem. A trust registry is build on top of it to add the trust to the ecosystem. Approve ecosystem actors, credential schemas and other trust related topics.
Hope that helps!
| 1. **Data Export and Import Capabilities**: Users should be able to easily export their data from the wallet and import it into another wallet or system, using standard, non-proprietary formats. | ||
| 1. **Backup and Recovery Options**: Provide secure and intuitive backup and recovery options to ensure that users can regain access to their wallet even if their primary device is lost, stolen, or damaged. | ||
| 1. **User-Centric Design**: Maintain a user-centric approach that prioritizes ease of use in transferring the wallet from one environment to another without technical barriers. | ||
| 1. **Decoupling From Hardware Constraints**: Design the wallet in such a way that it is not bound to specific hardware features, making it more adaptable to various technological contexts. |
There was a problem hiding this comment.
Totally agree with that principle but I fear that it could be misinterpreted that specific hardware feature should not be used. Thinking about TEEs, HSMs and proof of ownership (device bound credentials)
There was a problem hiding this comment.
Any suggestions for re-wording? It is definitely not the intent to limit the use of TEEs/HSMs, but rather trying to ensure that we have the ability to switch in libraries that support different hardware.
There was a problem hiding this comment.
Maybe something like "Design the wallet in such a way that it is not bound to specific hardware, making it interoperable with various technological contexts."?
After re-reading it, I think the risk of misinterpreting the sentence is really minimal. Both option work for me.
| 1. **Cultural Sensitivity**: Acknowledge and respect cultural differences in design and functionality, avoiding bias and ensuring the wallet is culturally relevant. | ||
| 1. **Robust Customer Support**: Implement a robust customer support system that can handle inquiries in multiple languages and cater to users from different cultural backgrounds. | ||
| 1. **Geographical Inclusiveness**: Ensure the wallet is legally and technically compatible in different jurisdictions, respecting the regulatory frameworks of diverse regions. | ||
| 1. **Device Variability**: Guarantee that the wallet's core functionalities are available across a wide range of devices, including older and less advanced models, to ensure no user is left behind due to hardware limitations. |
There was a problem hiding this comment.
Depends on the definition of core functionalities but that point could clash with architecture reference frameworks like the EU ARF which enforce device bound wallet attestations and PID credentials.
There was a problem hiding this comment.
Thanks for the feedback. I understand what you are saying. I am not sure that I know exactly how to resolve this comment. Let me think on this. If anyone has suggestions on improving the phrasing here, please let me know.
| - VC-API | ||
| - CHAPI | ||
| - Aries Interop Profile | ||
| - Verifiable Data Registries |
There was a problem hiding this comment.
Verifiable data registries only mentioned but not described what they do.
There was a problem hiding this comment.
This entire section is about things that already exist that could be used as enablers for implementation. We may want to consider describing all of these items. What do you think?
There was a problem hiding this comment.
Not sure if everything needs to be described but i would say that the idea of having a Verifiable Data Registry and a Trust Registry is universally accepted but the separation of duty between both depend on the interpretation.
The other points are transport protocols, APIs to interacts with actors, interop profiles, etc. for me they seem to be on a deeper technical level than a architectural view of a universal wallet. What the wallet need is to be designed to be multi-stack based and to easily add new protocols, APIs in the future.
I like to compare the current wallet situation with the early days of browser where competiting specifications were implemented in browsers and the more dominant / futureproof specification survived the years.
|
Thanks Tracy, that's an impressive first take. The paper defines two authentication use cases (which are very relevant), 1/ authenticate to access your wallet and 2/ use your wallet to authenticate towards another service. Hence, I'd suggest that under Technology Enablers we also list FIDO2 next to OAuth/OIDC. |
Signed-off-by: Tracy Kuhrt <tracy.a.kuhrt@accenture.com> Signed-off-by: Tracy A. Kuhrt <tracy.a.kuhrt@accenture.com>
Signed-off-by: Tracy Kuhrt <tracy.a.kuhrt@accenture.com> Signed-off-by: Tracy A. Kuhrt <tracy.a.kuhrt@accenture.com>
Signed-off-by: Tracy Kuhrt <tracy.a.kuhrt@accenture.com> Signed-off-by: Tracy A. Kuhrt <tracy.a.kuhrt@accenture.com>
Signed-off-by: Tracy Kuhrt <tracy.a.kuhrt@accenture.com> Signed-off-by: Tracy A. Kuhrt <tracy.a.kuhrt@accenture.com>
Added. Thank you for the feedback. |
Signed-off-by: Tracy A. Kuhrt <tracy.a.kuhrt@accenture.com>
Signed-off-by: Tracy A. Kuhrt <tracy.a.kuhrt@accenture.com>
Signed-off-by: Tracy A. Kuhrt <tracy.a.kuhrt@accenture.com>
Signed-off-by: Tracy A. Kuhrt <tracy.a.kuhrt@accenture.com>
Signed-off-by: Tracy A. Kuhrt <tracy.a.kuhrt@accenture.com>
No description provided.