# Sign in With Ethereum Community Call #14

### Date: 2022/05/12
### Agenda:

- [General] Reader Notes & Updates
- [General] Introductions
- [Show & Tell] SIWE Updates (EIP-4361 review status, API Harmony / 2.0, Demo for Auth0 functionality, current initiatives)
- [Q&A]

## Relevant Links
- [SIWE 2.0](https://github.com/spruceid/siwe/releases/tag/v2.0.3-beta)
- [Auth0 Demo](https://auth0-demo.login.xyz/#/)
- [EIP-4361 to Review](https://github.com/ethereum/EIPs/pull/5034)

## Reader Notes and Updates

- SIWE TypeScript library is out and can be found [here](https://github.com/spruceid/siwe).
- The [Discord](http://discord.gg/WjvuYqvm5Y) server is always open for questions and those that wish to participate.
- We're working on support for different templates, languages, and more - please reach out if you're interested in a SIWE integration.
- Documentation: if you're about to embark, let us know what you think would be best to include! All feedback is welcome.

## Introductions
- [Pshemek] - Stack is Fastify, works on TrueFi, has use for Sign-In with Ethereum. We integrated and have extracted the work Spruce has done as packages for Fastify.
- [Avi] - Pretty new to the space, met Rocco and Wayne and ETHDenver. First product hire for Ceramic, and the part that Ceramic does is store app data and let's users control it.
- [Ark Huang] - Developer from the Fox Wallet team. It's a wallet that supports the Filecoin ecosytem but now supports the Ethereum ecosystem. We're integrated in supporting SIWE.
- [Damien] - Part of Auth0 and feeling out apps in the web2 and web3 world.

## Show & Tell
- EIP-4361 changes - moving from `Draft` to `Review` in order to avoid any confusion about the spec.
- [Wayne] - We're sharing that we're releasing the Sign-In with Ethereum 2.0 libraries. We had many language implementations and we wanted to harmonize everything to one API. Oliver from Spruce led the work there and I want to talk about the work of that harmonization.
- Basically, a few big changes. We figured out a way not to have any breaking changes - just warning messages. We thought the interface changes were large enough to merit a new version. Wallets didn't care about verifying the signature, just creating it. They didn't want to pull in the entire cryptographic library for that, so we split out the SIWE parser into its own package so any project can validate that. It makes it a lot easier and with a lower footprint.
- Another refactoring is that we've deprecated the validate name and named it to `verify` with the new API. It may be backwards compatible for now but it would be removed in future versions.
- We also decoupled `ethers` as a peer dependency so this library doesn't bring in a different version of `ethers` if you're already using it.
- We're also validating `eip-155` as part of the spec, and we separated concerns from what is actually in the SIWE message and what you're trying to verify it against. Finally, we added checks for `not-before`. If you're upgrading to the latest version, you'll just get a warning message that `validate` has been deprecated. If you're really curious about what `verify` brings to the table - it brings in two arguments: `params` and `ops`.
- The parameters are the signature, the domain, the nonce, and the current time. We might want to verify things in the past which is why time is included. Options are what's the way we verify things - this affects the code paths. If we want to use infura, alchemy, or any other provider, you can do that. We need this during verification of EIP-1271, smart contract accounts, so you have customizability for providers. We can suppress exceptions - normally we throw it if things fail to verify. If you're extra sure you're going to check the output, you can suppress this.
- The other implementations will follow suit but this is maturing the library, making it more composable, and truly a public good.
- [Ark Huang] - Just a quick question. Do you have a plan to support more language libraries? Do you plan on supporting Java?
- [Wayne] - Java is actually on our list at the moment.
- [Oliver] - One of the things that we worked on - SIWE was recently added to the Auth0 marketplace so implementations can use Auth0 for SIWE for login. Their username would be their ETH account or ENS name. We've also created a demo application so folks can see how it all works. The implementation is quite simple due to the Auth0 vue.js template.
[ Demo of the example ]
- [Wayne] - One of the exciting implications of the IdP work, is that it could have credible neutrality. If any SaaS software uses the enterprise plan where you can bring in your own identity provider, you can set that as the SIWE IdP.

## Q&A

- [Adrian] - A couple of you may know about the W3C type of operation - what's the difference between WalletConnect and CHAPI?
- [Wayne] - CHAPI stands for credential handler API - this is so the browser can request credentials from the user. The similarities are - WalletConnect can serve as a web3 provider, providing web3 functionalities to the browser. CHAPI is the interface for the credential provider itself. One brings the ability to ask for credentials, web3 providers allow you to bring blockchain functionality from the user. I can imagine a universe where they work in tandem. I know Google is working on FedCM (federated credential management for auth tokens). Does that help?
- [Adrian] - My impression is that WalletConnect can do everything that CHAPI does.
- [Wayne] - I would say it's similar in that it's a pipe where you can send things, but at the same time, I would say that to me, WalletConnect feels more like establishing a transport layer, and CHAPI is more interfaces specialized for asking for credentials. CHAPI rides more on the application level while WalletConnect is brokering a transport. FedCM seems the closest with respect to CHAPI.
- [Avi] - Curious - your thoughts on emerging apps around credentials and reputation?
- [Rocco] - Sismo, Disco - Wayne?
- [Wayne] - We're seeing a few companies come up around reputation - I think that it's multi layered. A few folks have different approaches and now the conversation is moving toward tokens and verifiable credentials as these separate items. It's more useful and constructive to talk about where a signed statement about reality lives, is shared, etc. - I think that as we evolve into those kinds of features, we'll figure out better ways of using things. In terms of projects - I think there will be a lot of alignment soon around schemas to do social credentials. Spruce and Ceramic have been working on this together. This is called Rebase, where it imagines a world with multiple issuers.
- [Avi] - Haardik mentioned this as well.
- [Wayne] - If we can bridge it with Sign-In with Ethereum, then we have the full end to end flow with these interactions. That's the flow that allows us to fulfill the UMA flow where a user brings their data to the session.
- [Alec Wantoch] - Regarding Rebase, i'm glad that naturally came up. Would love to collaborate on this and jump in!
- [Wayne] - We're hoping to publish our thoughts on this in open publications, and maybe figure out what a community call would look like for this / structure it as a public good. Another thing that isn't figured out but if anyone is interested in working on this: what is the canonical way to go to a VC to an on-chain representation. What if we don't project all the data, but a subset or specific fields? Or maybe it's in a smart contract or encrypted smart contract, etc. There has to be some way, but it would be extremely constructive if someone did. If you're interacting with a dapp protocol, there's no verifier server to check the signature in the credential.