The Last Straw for Alice & Bob, the Tide That Never Rises | Discover the biggest problem in decentralized identity. Is your wallet strategy amplifying its harms to your product & org? You can't fix a problem you don't know you have.
IMHO you may not need a single wallet for all potential purposes. It may be too complex, too complicated, too user hostile. There are credentials which you may use daily, and others which you only use once in a while. You do not need to keep them together. Especially that credentials and use cases have different transaction specifics ,there are no homogenous user journeys which would demand one uniform approach, UI, etc.
You may consider the mobile phone as the wallet. And have single purpose or multi purpose wallet applications therein. A bank will value a banking wallet more with additional banking functions and self-branding than a multi purpose wallet where you can also store your diploma or birth certificate, next to your bank card. Some credentials need more privacy and security than others. Combining them into a single wallet may either compromise the real sensitive ones or unnecessarily inflate the cost of the of those which could be satisfied with lower level security.
There are only two points where the global ecosystem needs to be considered, and these are crucial. Delivery (provisioning) and presentation of credentials. In these two aspects full interoperability, transparency and uniformity is needed for all other aspects generic or purpose built wallets could finely coexist.
Andras, thanks for taking the time to weigh in! There are a couple use cases I keep coming back to as a way of testing my thinking, which lead me to think that single-purpose wallets will not take us as far as we want to eventually go in this space (probably should have raised them in the post but may include in a future post):
1. Buying/leasing a car — where the buyer needs to minimally prove right to drive (credential from motor vehicles agency of government), insurance coverage (credential from insurance carrier/agency), financing (either financing-approval from an outside lender or multiple credentials, such as employment status credential from employer, to apply for dealer's financing), etc.
2. Registering a child for the first year of school — where the parent/guardian may need to minimally prove current residence (any of various credentials might suffice), age (likely a birth certificate from the appropriate issuer in the location where the child was born), vaccination status (credential from a doctor's office or healthcare system), etc.
In complex and cross-domain interactions like these, it's going to be very difficult for users to bounce from app to app to app to app (and know which app has a credential which will meet the requirements for each specific purpose), right? If you're envisioning a different pattern for this, I'd love to hear about alternatives.
I agree that some credentials will be more sensitive than others — calling for various levels of privacy and security. But I don't see any harm in keeping relatively low-stakes credentials in a high-privacy, high-security wallet. As long as you need to keep highly sensitive credentials somewhere, you're already taking on the burden of managing a wallet for those. Spreading credentials out across multiple wallets seems like it only adds to the baseline burden the user undertakes for whatever is her most sensitive credential(s). Each wallet adds some burden to the user, no matter how easy it is to use — even if it's just remembering which wallet is which and for which purposes each one is appropriate or useful.
Again, if I've missed or misunderstood part of your point there, please correct me!
None of this is to say that a bank or university or government agency couldn't have their own app, to support the features that are useful for interactions between a user and their institution. But I feel like we need a way for each of those apps to request a verifiable presentation of credentials that are required from the user's chosen wallet. There are many contexts where I need to prove my insurance coverage, which would happen outside of my insurance company's app. So I think a pattern like this (e.g. CHAPI, perhaps) is needed no matter what, even for a single-purpose wallet (e.g. my insurance company's app). Assuming we indeed need this pattern, I believe the best experience for the user is to allow them to use their own chosen wallet for all requests for verifiable data about them.
I'll appreciate learning where I've gone wrong above, so please let me know, if you've got the time. If a call would make sense to discuss, I'd be happy to find a time. Feel free to DM me on LinkedIn, if so (http://linkedin.com/in/danrxn/).
IMHO you may not need a single wallet for all potential purposes. It may be too complex, too complicated, too user hostile. There are credentials which you may use daily, and others which you only use once in a while. You do not need to keep them together. Especially that credentials and use cases have different transaction specifics ,there are no homogenous user journeys which would demand one uniform approach, UI, etc.
You may consider the mobile phone as the wallet. And have single purpose or multi purpose wallet applications therein. A bank will value a banking wallet more with additional banking functions and self-branding than a multi purpose wallet where you can also store your diploma or birth certificate, next to your bank card. Some credentials need more privacy and security than others. Combining them into a single wallet may either compromise the real sensitive ones or unnecessarily inflate the cost of the of those which could be satisfied with lower level security.
There are only two points where the global ecosystem needs to be considered, and these are crucial. Delivery (provisioning) and presentation of credentials. In these two aspects full interoperability, transparency and uniformity is needed for all other aspects generic or purpose built wallets could finely coexist.
Andras, thanks for taking the time to weigh in! There are a couple use cases I keep coming back to as a way of testing my thinking, which lead me to think that single-purpose wallets will not take us as far as we want to eventually go in this space (probably should have raised them in the post but may include in a future post):
1. Buying/leasing a car — where the buyer needs to minimally prove right to drive (credential from motor vehicles agency of government), insurance coverage (credential from insurance carrier/agency), financing (either financing-approval from an outside lender or multiple credentials, such as employment status credential from employer, to apply for dealer's financing), etc.
2. Registering a child for the first year of school — where the parent/guardian may need to minimally prove current residence (any of various credentials might suffice), age (likely a birth certificate from the appropriate issuer in the location where the child was born), vaccination status (credential from a doctor's office or healthcare system), etc.
In complex and cross-domain interactions like these, it's going to be very difficult for users to bounce from app to app to app to app (and know which app has a credential which will meet the requirements for each specific purpose), right? If you're envisioning a different pattern for this, I'd love to hear about alternatives.
I agree that some credentials will be more sensitive than others — calling for various levels of privacy and security. But I don't see any harm in keeping relatively low-stakes credentials in a high-privacy, high-security wallet. As long as you need to keep highly sensitive credentials somewhere, you're already taking on the burden of managing a wallet for those. Spreading credentials out across multiple wallets seems like it only adds to the baseline burden the user undertakes for whatever is her most sensitive credential(s). Each wallet adds some burden to the user, no matter how easy it is to use — even if it's just remembering which wallet is which and for which purposes each one is appropriate or useful.
Again, if I've missed or misunderstood part of your point there, please correct me!
None of this is to say that a bank or university or government agency couldn't have their own app, to support the features that are useful for interactions between a user and their institution. But I feel like we need a way for each of those apps to request a verifiable presentation of credentials that are required from the user's chosen wallet. There are many contexts where I need to prove my insurance coverage, which would happen outside of my insurance company's app. So I think a pattern like this (e.g. CHAPI, perhaps) is needed no matter what, even for a single-purpose wallet (e.g. my insurance company's app). Assuming we indeed need this pattern, I believe the best experience for the user is to allow them to use their own chosen wallet for all requests for verifiable data about them.
I'll appreciate learning where I've gone wrong above, so please let me know, if you've got the time. If a call would make sense to discuss, I'd be happy to find a time. Feel free to DM me on LinkedIn, if so (http://linkedin.com/in/danrxn/).
Thanks again for taking the time, Andras!