1. Sds-Wg
  2. Topics

Password Manager use case for EDV identifiers

Adrian Gropper
 

The 21/1/7 meeting was very helpful. Thank you for bearing with me to understand the identifier issues. 

To see if I get it, here's one use-case where a secure mobile wallet acting like a common password manager needs confidential storage beyond what it can store and recover locally. This is meant to be the simplest of use-cases. Alice is the only person involved and she does not plan to provide access or delegation to others any more than she would provide access to her mobile wallet / password manager to others.

That said, Alice wants to trust the confidential storage is reliable and accessible from all of the devices she controls that want to host a password manager. Alice also uses a DID to authenticate into her password manager. In case she loses the mobile that hosts her password manager app, Alice wants to be able to recover access to a new mobile device that is initialized with the password manager software and then use the recovery procedure of her DID method along with the plain-text address of her account at the confidential store.

In the sequence below, I'm using the roles (RO, AS, EDV) as described in these slides. This password manager use-case is closest to A4 - New Service Registration.

  • Sequence 1 - Initial Storage

    1. Alice’s wallet (RO) creates a same-domain edvDID for the EDV service.

    2. Alice pays one year’s rent to register her edvDID with the EDV.

    3. In local storage, Alice has a JSON-encoded file named ‘Policies File’ with her AS agent policies. 

    4. Alice registers an AS notification service endpoint in case of EDV exceptions.

    5. RO encrypts the Policies File with some IV.

    6. RO hashes the IV.

    7. RO re-labels the Policies File name with the hashed IV.

    8. RO sends the file to the EDV.

    9. RO uses Alice’s DID to encrypt edvDID, the EDV address, file encryption key, human-meaningful filename, and the hashed IV locally as an index cache.

    10. RO stores the encrypted index cache to the EDV as a separate file.

    11. RO stores the EDV address as plaintext somewhere in case of RO loss knowing that everything else at that EDV can be recovered when she recovers her DID.

  • Sequence 2 - EDV Replication

    1. EDV changes the path to the file.

    2. EDV notifies Alice (via the registered service endpoint) of the exception.

  • Sequence 3 - RO Recovery

    1. Alice loses control of her RO.

    2. Alice recovers her DID Document

    3. Alice retrieves the encrypted index files from the EDV address and recovers her EDV files.


This sequence is not meant to be an optimal solution. Please improve it.


- Adrian

1 - 1 of 1