kdenhartog
commented
4 years ago There's been quite a few discussions on this topic and unfortunately we haven't found a great solution yet. For an overview of the different considerations see this issue
Here's a good document we used to outline the problem better: https://docs.google.com/document/d/1CCu2w9QmWthw91OM1aGpwGZxppr-HeC_hRDgmQx6Ips/edit#heading=h.7ldfcn1lhazh
Here's a good doc from @swcurran that goes into detail about using VCs to solve this problem: https://docs.google.com/document/d/11XuLViz_epUuP1fzqcfn9f96tD17RLNDlNaF-XfmJ4o/edit#
Looks like the Sovrin Crypto call also looked at the problem on July 29th, 2019. The meeting notes are here: https://docs.google.com/document/d/1M3zgsRoOxlkjNPbDp4_7YWxuqO2EyefOT3Bt7ZgGIDY/edit#heading=h.4i2ma8bpbnrt
The latest approach that I think is worth exploring is option 5 in the first link. Here's a link to the academic paper on the topic: https://www.researchgate.net/publication/333443762_Password-Authenticated_Public-Key_Encryption
So in total, there's been quite a few different methods explored for this, but nothing other than generally using VCs has made it's way into the RFCs yet.
Hello!
Let's assume the following scenario: an electric vehicle (EV) wants to charge at a charging station (CS). In order to do so, both the EV and the CS need to authenticate and authorise each other. Specifically, the EV needs to prove that it has a valid charging credential (i.e. signed by an authorised charging service provider), and the CS needs to prove that it belongs to a valid charging station operator (CSO).
To prevent correlation attacks, both parties need to use temporary DIDs valid only for the scope of this charging transaction. Plus, the whole communication takes place over Bluetooth, which does not provide any security properties.
My question is: what would be the best way to link the temporary DIDs to the authentication and authorisation status of the parties? If an attacker would sit in between the two parties, it could establish communication channels with both CS and EV, and then proxy the proof requests and proofs so that it could authenticate itself as a valid CS to the EV and as a valid EV to the CS. This is possible because the proofs, by design, are not tied to a specific DID, but to a link secret.
The best solution that I have found so far is to have a set of "certified" DIDs issued each in a different VC, and during the communication the parties also need to prove that the DID they are using has been certified by some third-part authority. This, thought, kinda goes against the principles of Indy, for what I know.
Do you have any ideas? Thanks a lot!