fabricedesre
commented
2 years ago Hi @Gozala ! Thanks for the comments.
I’m bit confused here is each DID rough equivalent of a user in unix system ?
Somewhat... The idea being you could create for instance different DIDs to use in different contexts on the same device - maybe personal vs. pro or even create a "guest" DID for temporary usage.
About core apps having always-on full-access, I tend to agree with you that something more granular would be better. I'll see if I can implement that by declaring requested capabilities in the app manifest. There are situations where you really don't want to prompt the user, like accessing the wallpaper, etc. so that needs to work at first run with implicit trust by default.
I would argue this may not be that different from what you can do on the web platform or specifically from site_b.com embedding site_a.com into hidden iframe and using message passing to invoke capabilities.
Yes, it's not much worse than the current web model you describe, but we should aim at being better :)
I think what might help empower user is capturing all the UCANs in rotation in some “system access” interface so user is always able to revoke access. This way user participation can be more indirect, instead of prompting every time cross origin delegation occurs user can be shown a more passive status indicator that they can act upon (Apple does that sort of a think when geolocation, microphone, webcam etc… is used)
In such a “system access” interface it might be useful to allow user to e.g. forbid certain origins from gaining access to certain capabilities, even if they were delegated.
Yes, I will build a management UI - I'm just a bit worried about information overload for users.
If you mean something like a smuggling of UCANS where one site might intentionally smuggle UCAN along with the keypair, that is certainly possible, but in that case sites are conspiring together and both are malicious.
It can also come from a breach, with no malicious intent from the site that was trusted in the first place. I don't think the attacker needs to steal keys to use the UCAN afterward, right? Of course they still need to trick the user to open the attacker site.
I think it is worth considering short lived UCANs that could be renewed without user prompts within certain timeframe. Something along the lines what browsers are already doing with storage of sites you visit only indirectly. E.g. if user is not actively using a site it’s probably better prompt user on UCAN renewal, if user is actively using site to which they’ve granted capabilities, it’s probably better to renew capabilities without interfering into user flow, especially if user can always revoke sites capabilities.
Excellent idea, automatic renewal makes a lot of sense when there is repeated usage! The fact that UCANs have baked in support for validity timeframes makes that very clean also.
I think DIDs private key should never leave the device as it creates opportunity for keys to leak, furthermore it would make stolen / lost device a real hazard. Each device having own keys seems better, although it creates UX challenge when designing interface for revoking apps / sites capability across all devices.
I also would rather keep all private keys in non-extractable secure storage. As you note there are tradeoffs between threat model and UX here. I'm also looking at using hardware keystores such as Ledger devices, and for multi-device use to keep keys on a single device and establish a secure channel with the secondary ones. No implementation yet :)
Gozala
Hi @fabricedesre!
I wanted to ask / start conversation on some of your UCAN findings. Hope this is a good place to do so:
I’m bit confused here is each DID rough equivalent of a user in unix system ?
To me it seems that core apps having access to “superuser” DID is probably not ideal, maybe instead they odd to just be allowed to skip user prompts ? That potentially would allow user to revoke core apps access e.g. by going to “system settings”. I also imagine not all core apps need access to all the resources, so having separate DIDs / UCANs there might also be a good way to lock that down.
I would argue this may not be that different from what you can do on the web platform or specifically from site_b.com embedding site_a.com into hidden iframe and using message passing to invoke capabilities.
I think what might help empower user is capturing all the UCANs in rotation in some “system access” interface so user is always able to revoke access. This way user participation can be more indirect, instead of prompting every time cross origin delegation occurs user can be shown a more passive status indicator that they can act upon (Apple does that sort of a think when geolocation, microphone, webcam etc… is used)
In such a “system access” interface it might be useful to allow user to e.g. forbid certain origins from gaining access to certain capabilities, even if they were delegated.
I think this might be misleading. Leaked and stolen UCANs can not be exercised without also stealing private keys associated with them. For that reason most web uses of UCANs go with non extractable private keys so they are tied to origin and can not be leaked.
If you mean something like a smuggling of UCANS where one site might intentionally smuggle UCAN along with the keypair, that is certainly possible, but in that case sites are conspiring together and both are malicious.
I think it is worth considering short lived UCANs that could be renewed without user prompts within certain timeframe. Something along the lines what browsers are already doing with storage of sites you visit only indirectly. E.g. if user is not actively using a site it’s probably better prompt user on UCAN renewal, if user is actively using site to which they’ve granted capabilities, it’s probably better to renew capabilities without interfering into user flow, especially if user can always revoke sites capabilities.
I think DIDs private key should never leave the device as it creates opportunity for keys to leak, furthermore it would make stolen / lost device a real hazard. Each device having own keys seems better, although it creates UX challenge when designing interface for revoking apps / sites capability across all devices.