Power of Attorney / Mandating / Guardianship

[rabomarnix]

I'd suggest to take Power of Attorney into account during architecting the engine, as this is very complex matter. It might be required by government agencies.

It depends whether this concept can be in scope or not. For example, it can be issued as a credential just like any other credential issuing process. But in other cases you might want to gain access to a wallet and share data on behalf of this person.

[dhh1128]

There are at least two different ways of representing someone else.

One form is opaque to the outside world. Classic example: Grandpa says he can't figure out how to make his wallet do what he wants, so he asks Granddaughter to help him. He authenticates with the wallet biometrics and then hands the mobile device to her so she can work her magic.

To my knowledge, there is no way of modeling or preventing this usage pattern in wallets, and it doesn't need to be accommodated in the architecture.

The other way is transparent to external parties -- they know that party X is acting for Y. An interaction like this has the same effect as a human conversation where someone says, "Hi, I'm X, and I'm representing Y as Y's attorney. Here is proof of that relationship: .... Now, as X, I take the following action on Y's behalf."

This second way of doing things does not, it seems to me, require that X have access to Y's wallet. Rather, it requires that X have their own wallet, and it further requires that X have a credential in their wallet that justifies the assertion that they are acting on X's behalf.

I am in favor of modeling in a wallet the features that would allow the second behavior, but I am optimistic about the impact on architecture being very light. That's because most of the complexity is shifted away from wallet interfaces and toward credentials and interaction protocols.

I am not in favor of modeling guardianship and power-of-attorney as a first-class wallet construct, because I think they are mostly legal constructs that can be implemented above a wallet. However, one possible feature we could consider is escrowed key support that enables a sort of "break the glass" feature (in an emergency, break the glass to gain access, knowing that it creates irreversible evidence that the glass was broken). It could be opt-in, so a wallet owner must agree to it, and it could use the front door rather than a back door -- meaning that it uses no subverted crypto, and no hidden access. Rather, the user is told, "If you are ever incapacitated, or if you are served with a legal subpoena, do you want to escrow a key that will unlock your wallet, with the proviso that the key's release from escrow is performed by a smart contract using code you can inspect publicly, guaranteeing impartiality and transparency?"

Users who answer yes to a question like this could know that their wallets can be taken over by someone granted power of attorney or guardianship by the courts, could know that their spouse can access their wallet if they die, etc. And users who answer no could know that they have no such fallback, for better or worse.

[thomas-tran]

@dhh1128 There are 2 solutions to your use case

1. You may use the capabilityDelegation verification method within the decentralized identifier document to delegate the owner capability to other party to access protected functions or API endpoints. Here is the definition of the capability delegation and the authorization capabilities linked data use cases
2. Another solution is using the verifiable credentials as you mentioned in the use case. The similar use case Digital Executor (law) is described here