11K/ Sign-In With Ethereum (AuthN)
Sign-In With Ethereum (AuthN)
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:
Dedicated website for the project (includes research, notes, and recordings for community calls)
Demo for Kepler, our ZCap-based “EDV” storage solution (Q&A at demo table)
Wayne - Screenshare
Metamask - 10mil MUA
Context: AuthN, “accounts” in Web3 zone
Context: example of OpenSea
Site overview (links to community calls)
Screenshare of Supporters section - User research
Spec in more detail
EOA/SC addresses - no 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_?
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…