22K/ not-so-smart wallets

From IIW

Session Title: not-so-smart wallets


Thursday 22K

Convener: Kim Hamilton Duffy, Orie Steele, Darrell O’Donnell

Notes-taker(s): Kim Hamilton

Tags for the session - technology discussed/ideas considered:

wallets, agents, dids


Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps: 


Context (Kim’s presentation)

  • Goal: Tease apart wallet-related concepts

  • Based on CCG's survey of wallets

  • Highlights (see slides)

    • DIF Glossary report

      • the relationships are interesting

    • Darrell O'Donnell’s wallet report

      • tease apart wallets vs agents and also minimum viable wallet

      • his wallet definition matches DIF glossary definition

      • Stuff as a proper noun

  • Question: is a wallet hot, dumb, secure storage? What are we missing?

  • Reviewing Darrell O'Donnell's minimum viable wallet

  • Why do we care? universal wallet interop spec -- what goes in there?

  • Maybe there is some awareness of entities it's connected to when we talk about "wallet". Tease apart what these concepts are.

Discussion:

  • Sam: What’s missing from this presentation is that many wallet designs have crypto happening in the wallet.

    • Discourage devs from doing stupid things with keys

  • Wallet and public-facing abilities

    • Keith: Portfolio/credential management is a wallet feature in workday wallet

    • Orie: Conceptual mismatch about wallet exposing publicly shareable info. Are we exposing an interface that shouldn't be exposed?

    • Keith: wallet helps manage

    • Kim: The way we talk about wallets in LER space is different. More like portfolios.

    • Matthew: There may be a central location for storing / curating data, then I can publish/curate data, and authorize access through some agent protocol. Publish in some way that they can either access immediately or access via an endpoint. Managing access to data via some policy (wallet controls or public)

  • Discussion about trust model

    • Bart: things at edge need to be zero trust. What if you as an issuer have certain security requirements of a wallet? What if I spoof a capability I don't have?

    • Orie: Apple -- apis expose certificate chain to prove claim is signed from root. e.g. if I make a claim about a key being hardware protected

    • Darrell: accreditation and certification. Can I trust Bubba's wallet? Other concern is backup and recovery

    • Bart: Physical wallet -- different paradigm. Stuff inside wallet is secure, but not the wallet itself. Gap: digital wallet is supposed to "do" something -- sign presentation, do crypto. We should focus on that tiny gap, trust minimize the wallet. (rather than accreditation -- less scalable)

    • Tyler: placing trust on wallet misses the mark

    • Darrell: reality is putting things in/pulling things out. We have to figure out what I truly control. We need to tease apart what wallet actually does.

  • Corollaries to physical wallet:

    • Sam: worth teasing out some aspects. Curious about corollaries to physical wallet. Contents of physical wallet can be swiped.

    • Darrell:

      • Suppose I held a credential, but I lost the wallet. Important that there was a record that I got it. Backup and recovery is critical.

      • Name of digital wallet -- I wish we had a better name. I can't draw a crisp line

      • Issues like authorizing access (automatically) for health provider.

        • If it's my doctor, part of health system, and normal query

          • don't want doctor to have to ping me every time.

        • law enforcement: DL - sure

      • bar: DL - no, and maybe notify authorities

      • Some stuff is irrecoverable. Bearer asset that only exists in my wallet (e.g. cash) -- that scares the most.

    • tmarkovski: wallet importing/exporting goes along with. Interested in practical problems that can only exist in one instance and cannot be duplicated

  • Recovery as an attack vector

    • Darrell: recovery vector becomes the attack vector

    • Tyler:

      • Tying recovery to biometric provider. for providers that do biometrics right.

      • Wallet by itself is not enough

    • Sam:

      • I prefer social recovery, m of n recovery

      • I don't have a good handle on: if keys were in secure element and I lose that phone in the ocean, how do I get it on a new one. How do we mechanically do that?

  • Key management feasibility

    • Keith: a lot of individuals aren't prepared to do key mgmt. When they lost control, they became upset that they lost access to their credentials and had to be re-issued. Moved to custodial.

    • Darrell: there are ppl that won’t manage keys; e.g. if they are targets (known to carry a lot of crypto)

  • Different recovery modes

    • Orie:

      • data model - structured json: keys, entropy, metadata, credentials, author caps, etc

      • 2 scenarios for recovery:

        • locking and printing it out (single wallet, lock, save it to dropbox, etc)

        • sync to external service, e.g. secure data storage

    • Rouven: separate recovery and backup

    • Sam:

      • Difference between data being stored and software libraries used to prevent bad behavior

      • Don't think it's important that there's standardization of the libraries. More useful to have standardization of core data. Ability to take core data and stick it somewhere else is valuable. Move to another wallet, import it in a future version of the same, More important than hiding behind API.

      • Separately, Promoting good architecture to avoid bad key use

      • One about interop, other about preventing bad developer behavior

    • Keith: mobile vs web -- accessibility

  • Separation of concerns

    • Darrell: didn't need credentials for many actions when we already had dids. sending messages "do you approve transfer?" crypto sign using did. Crypto lives in wallet

    • Rouven: split wallets conceptually

      • secure thing in OS, holds some keys

      • many different applications that access or wallet OS level??

    • Orie:

      • browsers have software isolated key caps

      • progressive web app with dongle

      • metamask (trezor, etc)

      • sometimes intfc isnt' handled by wallet itself. wallet is way to ask for a signature, or to trezor to have a signature.

      • Ask for signature for wallet and have it only mean there's plaintext keys in wallet. Against security practice of teasing apart.

      • What's in a wallet vs capabilities

  • Dumb wallets

    • Discussed Bart’s claim that wallet is dumbest, lowest security thing that's useful

    • Orie: from security perspective, prefer non-extractable private keys. want hardware/software isolation. but for variety of reasons we can't get it. plaintext private keys. if you can afford to have hw/sw isolated and store capabilities in wallet, good. But there are cases where you can't do it or locked out of modern crypto (don't have hardware support)

  • Central vs distributed management of keys/devices

    • Rouven: central dashboard to manage devices, keys, revocation, etc. Is that mobile wallet?

    • Sam: responsibility of devices. circle, quorum of devices. Can't be one thing. Dont' like centralized service

    • Orie: trust graph

    • Rouven: Centralize logic / rules, run smart contract

    • Darrell: 737 cockpit

    • Orie: contract locks away token

    • Brent: skynet no kill switch

  • Context-aware

    • Orie:

      • Wallets have to be flexible to support security context relevant to ppl and businesses

      • different security properties, but speak about in same ontology

      • a way of relating security props of 1 system with another

Retrieved from "https://iiw.idcommons.net/index.php?title=22K/_not-so-smart_wallets&oldid=23489"