ChainAgnostic
CAIP-369 - Wallet Session Property for Personal Information
This CAIP introduces a new session property for use within CAIP-25 session negotiations, enabling dApps to request structured personal information from users through wallets:
- firstName
- lastName
- emailAddress
- phoneNumber
- shippingAddress
- billingAddress
Some people from fintech/wallet companies at DIF have been collaborating on a "sensible default" set of schemata for KYC info, complete with semantics, might be helpful here: https://identity.foundation/credential-schemas/#verified-person-schema
Note in particular that the convention in US fintech/compliance is to refer to addresses compressed into single strings/fields as unstructuredAddresses, as most backends use the "street address"+"street address part 2(optional)"+"city"+"state/province"+"zip code/mailing code" that's default in US apps...
I'd strongly urge us not to share personal data in a way that is directly connected to the wallet address. Today a wallet address is in the grey area of whether it's personal data or not and this would make the wallet address considered personal data definitively because it's now an identifier directly linked to personal data. That interpretation could then be expanded to say that because the transaction remains on the blockchain, it disables the RTBF past the typical 7 year window necessary to retain information for financial compliance and then put a bunch of services in non-compliance with GDPR.
What that means is that every wallet, site, and RPC service which are relaying this information around will be considered controllers/processors under GDPR and CCPA if operating from CA and need to have appropriate controls in place to comply with the laws.
While it's generally my view that we should treat wallet addresses as personal data anyways, in my experience, genuinely only one company I've ever spoken with actually has a Data Protection Officer and is prepared for dealing with GDPR. More often than not companies have not even spoken to counsel for advice on how to comply. Essentially, we're going to walk everyone into a compliance process by including this data directly in the wallet and supplying it to services and sites via the wallet.
I get the desire to improve UX with this, but the costs associated with GDPR and CCPA compliance alone are going to be a headache.
I'd suggest this information gets typed in by the user so it's only the burden of the site to comply with the linking of the personal data and the wallet address and they're a sole controller of this. That way wallets and service providers don't get caught in an issue of non compliance because they rely on this and don't realize the implications.
Fair enough! Personally do not have strong opinions on this particular approach but I believe that inevitably we will get to a point where this information will be provided by wallets
Travel Rule is one example where this might be useful but there are also several centralized solutions currently exploring a similar approach to allow ecommerce checkout experiences with self-custodial wallets
I would recommend us finding something that we feel comfortable to allow wallets to expose this information without requiring a centralized third-party
Yeah, I think it's going to be necessary it's more about when more than anything IMO.
Let's let this sit for a bit, because if we can make it so that wallet addresses either become ephemeral or are blinded by ZK proofs of knowledge in some way, then that is the time where it makes sense IMO.
Having something sitting though at least gives people the idea to look in this direction when you're talking with them. As more companies start thinking about these problems then we can see what the consensus direction to go is because I am a fan of trying to combine it for better UX, I just don't see a way to make the compliance simple quite yet.
What if we just merge this as is in draft form so it's published and you can link to it as needed?
Not urgent? Awaiting implementer/evaluator feedback/enthusiasm to devote cycles to fixing the privacy approach