Summary:

  • Mobile Infrastructure
    • Mobile Verifiers
    • Device Recovery (Backup/Restore/Sync/Rotation to new keys)
    • Secure Element usage
    • SDK / Embedding Agents into existing Mobile Apps

Note: This call was recorded and the recording and chat transcript are at the bottom of the page.

Date

(7AM-9AM Los Angeles)

Hyperledger is committed to creating a safe and welcoming

community for all. For more information

please visit the Hyperledger Code of Conduct.


Anti-Trust Policy:

Linux Foundation meetings involve participation by industry competitors, and it is the intention of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws.

Examples of types of actions that are prohibited at Linux Foundation meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy available at http://www.linuxfoundation.org/antitrust-policy. If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation.

https://zoom.us/j/93810537086

Attendees                                                                                                                                                            

Welcome / Introductions


Focus

Mobile Infrastructure

Discussion Topics

  • Mobile Verifiers
    • We need them.
    • Flow
      • Holder displays QR, Verifier scans with mobile app and sees the result. - Common Model, assumed by those new to industry.
      • 'presenting' the QR code feels natural when 'presenting' a credential.
      • QR is best as invitation, not requiring user to know in advance what to present.
      • Verifier can also display QR.
      • Speed of transaction
        • User prepares to have transaction happen fast
          • Preselect or preauthorize set of actions
          • Can be assisted by governance / trust registry to find common targets
        • build set of 'reapprovals' after done initially.
          • save my authorization
    • Unique Features
      • Offline Verifications
        • Can't use shortened QR codes
        • BLE Verification useful offline
          • Needs framework support
        • Machine Readable Governance - cached
          • Cache schemas
          • Cache public keys for verifiers?
          • Pass file? (Interaction)
        • NFC - Needs investigation
      • Common Hardware
      • Framework support required
        • Offline aware
      • UI Supports required
      • Cache Needed
      • User Experience
        • Clear for Holder
        • Clear for Verifier
        • Clear indication of where in the flow they are. Universal progress bar?
        • Particularly for non-happy paths
          • Internationalization / Localization
      • Performance
      • Auditing verifications
        • reporting verifications back to main org
        • minimal disclosure auditing
        • knowing what is stored/passed
    • Actions Items
  • Device Recovery (Backup/Restore/Recovery/Rotation to new keys)
    • Backup / Restore Formats?
    • https://w3c-ccg.github.io/universal-wallet-interop-spec/
    • Data Model + app specific in the same format?
    • Keep them separate?
    • Security of backups?
      • huge attack vector – e.g. family member restores backup to new device and uses data
      • Is it possible to disable an old phone when a restoration is done to a new phone?
      • Assumption is that encrypted backup goes one place, the recovery key goes elsewhere and the only come together for restore
        • Is there more that can be done?  Other protections?
        • Can this be done with self-service?  Is that safe enough?
        • Selective recovery – is that possible?
    • Some things that can't be backed up or restored
      • Example is a device-based keys – you can't back these up
        • If there is a credential somehow tied to a device key, that credential must be reissued (and that's OK)
    • How to do continuous backups (don't lose data)?
      • File format
        • File format for a full backup
          • Contents – connections, credentials, history
        • Will we have to do (more or less) continuous backup - full backup every time efficient enough vs. incremental?  Classic backup issues.
          • Treat this as an optimization for now
      • An RFC to define such a protocol to be used with a backup service – perhaps supplied by a mediator (but could be any connection).
        • Setup backup – location, recovery key(s) (format – e.g. passphrase? biometrics?), restoration process
        • Make backup – ongoing – data format
        • Retrieve backup for restoration
        • Restore backup using recovery key(s)
      • How can Mobile OS features help with this?
        • E.g. Backup/Restore of app data
  • Secure Element usage
    • Provinces Project - diagram, markdown - decisions when making a wallet.
      • starting point for security framework oriented folks.
  • SDK / Embedding Agents into existing Mobile Apps


Action items


Call Recording

  File Modified
Multimedia File GMT20211123-150030_Recording_2340x1746.mp4 Apr 26, 2022 by Ry Jones
Multimedia File GMT20211123-150030_Recording.m4a Apr 26, 2022 by Ry Jones
File GMT20211123-150030_Recording.transcript.vtt Apr 26, 2022 by Ry Jones
Text File GMT20211123-150030_Recording.txt Apr 26, 2022 by Ry Jones

  • No labels

1 Comment

  1. As an addition to the Device Recovery, I could imagine to generate a recovery key (with a list of ordered words) at the start by each user to encrypt their data (including did documents, private keys for verifiable credentials, etc).
    The recovery key could then be stored in a Keystore offered by the operating system (like Android with their Keystore which stores them in HSM when available). The access to the Keystore can be secured with biometrics or passwords and keys stored in them can not be exported. And if it is not enough, a random device specific encryption key could add an additional layer of encryption for local data.

    In conclusion the user would need to remember the list of ordered words  (and a new one in case of rotation) but the backups could be stored directly into Google Drive or iCloud depending on the operating system. It would make restoration straight forward when setting up a new device (with a Google or Apple account).

    I have also another issue but I'm not sure if it fits her. What if a user would want to use multiple devices at the same time?
    They could use the device recovery options to clone their credentials to multiple devices but it would quickly get out of sync.
    Maybe it would also help to have some sort of synchronisation protocol.