11K/ Sign-In With Ethereum (AuthN)

From IIW

With Ethereum (AuthN)

Wednesday 11K

Convener: Wayne Chang, Spruce Systems (NYC)

Notes-taker(s): Juan Caballero, Spruce

Tags for the session - technology discussed/ideas considered:

  • Authentication (maybe Authorization)

  • Security and Privacy Engineering

  • UX, Wallets, Web3

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

Important links

  • Dedicated website for the project (includes research, notes, and recordings for community calls)

  • Draft Spec

Spruce Links

  • Company Website, Discord server, and Developer Portal

  • Demo for Kepler, our ZCap-based “EDV” storage solution (Q&A at demo table)

  • Demo of Rebase Protocol, our self-serve identity assurance engine - (also available in more verbose version) (Q&A at demo table)


  • Wayne - Screenshare

    • RFP

      • Metamask - 10mil MUA

      • Context: AuthN, “accounts” in Web3 zone

      • Context: example of OpenSea

    • Spec overview

    • Site overview (links to community calls)

    • Screenshare of Supporters section - User research

    • Spec in more detail

      • EOA/SC addresses - no questions

      • ENS -

  • Questions

    • AGropp: metamask = only wallet?

      • WYC: yes, altho Oliver and I are working on other

    • Nader: high-level, what are advantages of SIWE over manual consent to specific actions?

      • WYC: 2 categories of ethN signatures - TXNs sent to nodes, and arbitrary data signing

        • We all agree arbitrary data signing is not great, partic if not standardized

        • Oliver: Caveat- Wallets implement a set of JSON RPC interfaces, not only for onchain use cases-- 191 is one of them

    • Malla: SIWE can be used with OAuth, you said; what are the use-cases for OAuth that you’re imagining?

      • WYC: Use cases: degen first

      • WYC: OAuth for web2 (one more button for OAuth companies)

    • AGropp: OAuth and uncorrelated stable identifiers?

      • WYC: That’s out of scope of this spec; you would use an HD wallet-derived keys for this, and what you’re describing is higher level

    • Oliver: is it a requirement that wallet vendors don’t change implementation?

      • WYC: Depends what you mean by “use this”

      • Oliver: this uses the dumb signature API; it’s “dangerous” because it looks like it works for the RP, without actually having any security

      • WYC: Let me finish this your and i’ll come back to domain binding normative requirements and other security issues

      • Oliver: why not ask more of implementers?

      • WYC: We’re interviewing them… the further we push, the less likely they are to commit and implement in the short-term.

    • Kyle: False rendering attacks?

      • %s - cross-site Scripting attacks (XSS_?

      • WYC: frontendSPA

    • Oliver: Is this ABNF extensible?

      • WYC: URI list is only extensibility

      • Oliver: RPs need to validate response against a versioned ABNF; version 1 RPs won’t be able to parse version 2 messages (WYC: SemVer)

    • Kyle: Augur’s prediction market

      • Kyle: They put a bunch of files on IPS accessed through an IPFS gateway - how would you domain-bind to an IPFS://?

      • WYC: you mean if ipfs:// demanded a signature?

        • Content hash str isn’t a very good UX

        • Kyle: it’s not authoritative anyways cuz it’s just a gateway

        • WYC: But IPFS has its own URI scheme

      • WYC: That’s a good point

    • Oliver: I’m confused-- you don’t propose JWTs because wallets don’t support it, but you impose domain verification (which they also don’t support)

      • WYC: UX tho; without wallet support, UX is terrible;

    • Juan: Oliver, could this signed string be represented as an EIP712 object? Are all these mandatory fields expressable first as an 191, later as a 712?

      • Kyle: DIDComm v1/2 analogy: breaking changes to v2, but if v1 works well no one wants to break anything - difficulty of incentivizing

      • Kyle: SSLv3 - only able to push people off of it at great cost and TLS 1 took forever; deferring safety to v2 bifurcates the market

      • WYC: Wallets are going slow; in the meantime

      • Kyle: Leverage conformance to pressure Wallets into an upgrade? What are the tradeoffs? You already have this forcing function, dApps are signing onto this spec and have adoption on your side…

      • WYC: But if we show the users an EIP712 JWT, these RPs will bail; their sign-in is contingent on good UX

      • Kyle: But we need to distinguish wallet UX and dApp UX…