# Sign in With Ethereum Community Call #1

### Date: 2021/10/01

### Agenda:
- Introductions
- Welcome messages for to the first Sign in With Ethereum (AuthE) community call.
- AuthE was an RFP put out by the Ethereum Foundation and ENS, Spruce is working on it but not the only contributor - we need community feedback to have a successful specification.
- Meeting videos and meeting minutes will be posted publicly in a timely manner after each call.
- Spruce introduction: focused on decentralized identity. Background was at ConsenSys, dealt primarily with bringing data to the space.
- Over 20 interviews conducted to date, notes will be consolidated and posted publicly. Still researching to make sure we have enough information to make informed decisions.
- Sign in With Ethereum Summary
- Being able to establish some kind of authentication that someone is holding the key behind an Ethereum address and can have access as a result. That's the base flow: you may have seen it on platforms such as OpenSea where users need to sign a message that includes accepting a Terms of Service.
- It's already being implemented (in somewhat heterogenous ways), and we have an opportunity to standardize how it is done, improves interoperability, provides a common ground so that wallets can provide a better UX (avoiding 500 slightly-different ways to sign in).
- Additionally, extensibility: how do we prevent identifier re-use in the future?
- We can also establish routes for more information about the session. How do we pull in additional on-chain and off-chain information in order to enrich the user experience.
- For the purpose of the spec, it's "how do you authenticate against an Ethereum address for the session".
- Community Introductions
- _Christian Felde_: Works for Web3 Labs - initially started working on a library called Web3j. Currently, very focused on a client project where DIDs are used.
- _Joel Thorstensson_: Co-founder of Ceramic Network - a peer to peer data backend for dapps. Before was at uPort helping to define the DID standard. Interest is to use Sign-in With Ethereum to sign into backend and also sign into peer to peer data storage.
- _SU_: Works for Ceramic - interested in making sure the end-result of Sign-in With Ethereum will enable authentication and authorization.
- _Ryan Li_: Works at Cybertino. Working on a social graph on top of Ceramic to build a social layer for any gaming application.
- _Mike Purvis_: Works at NEAR protocol - two things that got into blockchain: Unlock protocol and BAT.
- _Brantly.eth_: Director of Operations at ENS. Helped put together the RFP, and had a lot of highly competent people and picked one. Spruce is here to drive things forward but always looking forward to additional input.
- _Hadrien Croubois_: Smart contract engineer at Open Zeppelin. Used to dedicate a lot of time to the ENS login project. Interest is in building the next steps of this original project.
- _Oliver Terbu_: Works at ConsenSys Mesh. Working in identity for 10 years and has major involvement in standards groups. Wants to see where the specification goes.
- _Rouven Heck_: Works at ConsenSys - worked in the past with Spruce and Ceramic members. Very keen on how to bring this together with some of the other efforts in other ecosystems.
- _Juliana_: Excited for the project, a developer involved in hackathons, developer relationships (Eth Sao Paolo) and deployed a DAO for women. Always talks to developers about authentication. Can help with UX and testing - additionally has a channel full of developers to help beta test and get additional input.
- _Praneeth Srikanti_: Represents Ethereal Ventures, and investors in some of the projects that have been working on bringing better kinds of attestations to the space. Excited to see all of the efforts happening here.
- _Jordan Cooper_: Runs a venture firm at Pace Capital. Very interested in identity and has made many investments and curious about go-to-market and how to engage Web2 applications to evolve the identity model.
- Topic (Brantly): Mistake of Standards Process
- (Brantly) Gets too bloated sometimes: "the specification should be simple" and avoid "feature bloat." Want to make sure it's simple and easily extended in the future, and it can be further extended if other things prove themselves.
- Topic (Rouven): To What Extent Did Functional & Security Requirements Come Up in Interviews?
- Off the top of mind we've observed a few:
- Preventing Replay Attacks and generate a nonce as part of the request. We've seen nonces from 5 random digits to random hashes to current block hash.
- Tightening the scope to a certain domain or service rather than 'works anywhere' = universal req.
- Terms of Service: many companies want users to accept a Terms of Service but this req varies by jurisdiction.
- Referring to additional claims and making sure what's being signed is limited in scope.
- Topic (Juliana): Storage at this MVP stage - just IPFS?
- The implementation plan for deliverables is to make it a pure SDK that doesn't do data persistance anywhere so new developers can add services.
- There's a deliverable that's an identity server (OAuth2) and this will be used as open source and we'd prefer users to run their own.
- Question: should we run a community provided version somewhere? Maybe a company can bootstrap it.
- Topic (Oliver): It Seems Spruce has Won the RFP - How Will Things be Published?
- We are going to be publishing a lot of what we submitted as part of the deliverables that get modified. We recently released our general approach and we're also going to be releasing the technical elements in follow-on posts.
- Topic (Hadrien): Issue: Smart Contract-Based Wallets Gaining Adoption - No Private Key?
- Smart contract-based wallets allow for us to solve a whole class of problems such as key management which will be one of the challenges that we face in the future. Multisigs could serve a helpful service here because if you have trusted entities, you can have easier key recovery solutions.
- (Rouven) Is this different than ENS with multi-owner/multi-key?
- Perhaps many servers that authenticate would check ENS / if matches a string.
- Can be a canonical workflow in this process.
- Has come up multiple times in conversations with DAO platforms - authenticate as collective.
- Topic (Sergey): Do We Anticipate Making This Approach DID-Method Agnostic?
- For this specification we have a clear focus on Ethereum addresses but that doesn't preclude any kinds of public/private keypair material for authentication processes.
- (Brantly) If there are simple ways to make it agnostic and widely useful that's great, but our focus for this is just the Ethereum ecosystem. If that applies to other places, great, but this isn't the all-encompassing standard for all things.
- (Rouven) At least for the conversation, sure, but I think we can conclude later if DIDs actually make things a bit more complicated - it's already an assumption whether it makes things harder. Most of the efforts on the DID side has already brought this down to the most minimal thing to define keys, signature schemes, and endpoints that would bring us to a conclusion.
- (Brantly) Open mind is good, there's going to be a strong force to bring in other things, but need to make sure this is simple, extensible and narrow. We can update things later.
- (Rouven) We want to avoid wallets building something different over the next 3-6 months.
- Topic: There are Many Signing RPCs, But EIP-191 Seems Dominant Over EIP-712 Because of Clear Text. Thoughts on Signing Methods?
- (Oliver) I think that this RFP should not invent new signing methods if the goal is adoption and standardizing what's out there. EIP-712 is nicer because you can see what you're going to sign and is flexible but the UX is not ideal. Can we use this to force wallet providers to improve the UX around 712? What I don't like is if we come up with something new.
- Goal is definitely not to invent a new signing method.
- (Sergey) Inside of Ceramic we had a discussion around signatures. It turns out that Personal Sign is readable for a person but it's not really readable wwhen there's a lot of text. There's often a plain wall of text, and it makes it really hard to post typed data or metadata that is critical to authentication and authorization and has to be displayed to the user to gather informed consent. Plaintext does not allow us to do that because it's just a simple wall of text. So 712 or a subset of 712 is optimal. We need to make sure it's not JSON so it's user-friendly and has a good display option.
- (Ryan Li) Structured data sounds better on the UX side, when we're reading messages of different sizes, different services have different way of organizing things and share certain things, but the way it's organized is pretty confusing. Maybe it's structured data and having the wallets support a custom type of structured data to unify the UX in the future.
- It sounds like everyone is agreed that structured data is convienient to encode security-sensitive parameters. What feels to be very optimistic is thinking that wallet providers will unilaterally create a good UX experience for 712 and that they would do it in a quick timeline. For example, the PR for Trezor still hasn't even merged it. If we survey the degree of support, what's the chance that wallet vendors would actually do it?
- (Hadrien): I agree that support for 712 is slow, we asked Ledger over 2 years ago, also the fact that 712 is still in draft should worry some of us. It's not a big deal but it would be better if it was final. However, there is a lot of incentives for wallets to support this.
- (Rouven): I think we have a chance to get the momentum here if we get this right and people will not reject it. I would be very nervous if we came back with a lower-security option. Some users might like things to look nicer but compromising on security is not what we want to suggest to the community and increasing the pressure for wallets to adopt it is better.
- (Oliver): One major security implication of personal sign is that users don't know what they're signing.
- (Rouven): That's part of the problem here.
- It's definitely an issue, and users should not be presented with a JSON blob in personal sign because that's even worse! I do think that when there are certain plaintext representations that make sense to the user, but this opens up a discussion on what's proper consent.
- (Oliver): We should provide some guidance to the user as to what they're accepting in the wallet.
- We should definitely discuss this and it should inform the decisions.
- Topic (Oliver): OIDC and OAuth2 Compatibility
- Summary: The approach for OIDC and OAuth2:
- Support OIDC as it is so services can just add the identity provider that can be constructed with the same SDKs that allow the users to sign in with Ethereum. After that's established, we can pass an OIDC token to relying parties using the normal flow. We should put a lot of effort to support the work out of SIOPv2.
- (Oliver): It's a centralized approach - we can host one as a community or the service can be commercial but it's still one central service. So SIOPv2 is the only decentralized option so if you want to go full-on OIDC and still be decentralized. Some people may complain that it's a draft, but it's already being implemented by the European Commission.
- It's important to consider what SIOPv2 support would look like. If the goal is to allow services to easily adopt it, there might be a non-profit that hosts.
- (Oliver): You can have the community host the provider and have wallet signing and we should talk about the OIDC endpoint. It's not a bad idea, and it's interesting.
- (Rouven): Who would be the initial customers of that, have you spoken to some who would want the OIDC option.
- We have started talking to Web2 services that are interested in hearing more about authenticating addresses.
- (Rouven): Just as an anecdote, when we showed uPort in 2016, typically when we talk to established big companies, most of them said, "okay but you're one provider - what are other people doing?" Most of them didn't want to pick a winner here, and an Amazon might not want to only support Ethereum and not BTC or another coin. If we have a specific solution, it'll be less interesting for Web2.
- It's a great consideration, and SIOPv2 is a decent approach, it's more aligned with the original intent of the OIDC authors. Both paths are valid and it comes down to tradeoffs: do web2 platforms care about this adoption and is it the only way they want to integrate?
- Topic (Oliver): Web2.5 Projects - Are You Talking to 2.0 Projects?
- (Brantly) Definitely a goal. We need to standardize this for the Web3 space which is first, but the idea would also be making an easy package to drop this into what services currently have.
- (Oliver) Standards compliance might be more important to traditional providers.
- We need to also make sure there's a singular interface here. Even a lot of Web3 companies are comfortable with this but what if they can use passport.js? Or what if it can be a module for Okta?
- (Rouven) Wouldn't that mean the community needs to agree on this one central OAuth2 server? Otherwise that means there's 3 login with Ethereum buttons? Logically it's only one central service.
- There would be one central server, but specifically for the peer to peer authentication without involving OAuth2 at all.
- Housekeeping
- Call time and community conversation (will continue as scheduled)
- Getting involved (join discord, follow twitter)