# Sign in With Ethereum Community Call #12

### Date: 2022/03/17
### Agenda:

- [General] Reader Notes & Updates
- [General] Introductions
- [Show & Tell] SIWE Updates (Auth0 marketplace, Discourse plugin, go / nextauth on deck, cleanup)
- [CACAO Presentation]
- [Q&A]

## Relevant Links
- [Documentation Portal](https://docs.login.xyz)
- [ENS DAO Draft Proposal](https://discuss.ens.domains/t/ep10-executable-a-dao-governed-identity-server/11125/24)
- [ENS Snapshot Vote](https://snapshot.org/#/ens.eth/proposal/0x104eb11d42813fadc2b408856e8fa2c10e34dbb4a87abaa2f089ece124263f16)
- [CACAO Spec](https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-draft_cacao.md)
- [CACAO Repo](https://github.com/ceramicnetwork/cacao/)
- [CACAO PoC](https://github.com/haardikk21/cacao-poc)

## Reader Notes and Updates

- SIWE 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 languages and plugins, 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.

## Joel Presentation
- [Joel] - CTO of 3Box labs, working on Ceramic. Will be presenting with Haardik on presenting CACAOs. We were first playing around with something using EIP-712, but SIWE provides a great approach.
- Core problem: Ceramic is a P2P protocol for mutable data, and in ceramic, everything has to be signed by a user identifier. Generating that key has been a pain point and we didn't want a system where a user had to sign every message with a wallet. It makes sense for a financial application, but if you're typing a comment in a form, you don't want to sign everything you do with a wallet.
- What we've come up with: CACAO. Chain Agnostic Capability Object. Uses SIWE to delegate write permissions that's controlled by your Ethereum address. A session key is given rights to update your data that you delegate to. You say 'this session key has rights to this so it can sign on your behalf'. It might have access for a certain amount of time as well.
- That's the general idea of CACAO, and we wrote the specification to be primarily focused on SIWE, but it's chain agnostic. I'm going to link the spec in the chat. We take the signed message and encode a bunch of data in there. This is something WalletConnect is looking at as well to make authentication more seamless.
- [Haardik] - Let's hop into the demo. Running a local IPFS node, local Ceramic node, and a PoC app. The idea is that, as Joel mentioned, let's say I connect my wallet. The idea is that we have one key / DID that's associated with my ETH wallet, and we have a session key that was generated client-side in the browser that we can use to make consistent updates to the data object without constantly having to sign. Let's say we start with an empty JSON object with a streamID on Ceramic. I can click this authorize button which starts the SIWE process.
- You're presented with the SIWE message which asks the app to give access to your data on Ceramic. The URI is the session key, and in the resources is the Ceramic stream. You can do this for groups of data objects. We sign this message, and now the session key has the capability to make updates on my behalf. I can write whatever I want, and it has an expiry time of about a week. For the next week or so, this session key can be used to make however many updates.
- What we can actually do now is take the latest update, which is an IPFS CID, I can query my IPFS node to look at the data, which is presented as a JWS.
- [Joel] - Ceramic uses JSON Web Signatures.
- [Haardik] - We take this protected header, go to JWT.io, paste it, and these are the protected headers - the did:key which signed the message, the EdDSA algorithm, and there's a 'cap' property noting the capability which was used to make the update. We can then see the CACAO object on IPFS which is a 1:1 mapping from SIWE. At the end of the message is the signature generated from MetaMask.
- Just to demonstrate a bad path - if the session key tried to make an update without the capability, it would fail. I'm going to open it up to questions.
- [Joel] - If someone gets ahold of the session key, will they be able to log into the application - there isn't any concept of a backend here. They would just get write access to that specific resource. They wouldn't be able to sign into any service on your behalf and this object is valid for a day or a specified amount of time.
- [Haardik] [explains the expiry on the capability].

## Q&A
- [Wayne] - I think this is great work and I think it makes a lot of sense to make a CBOR representation and using JWTs is a good decision. In terms of key revocation, let's say we make the session key for a week and the user loses the key - what are some ways we can think about for revocation.
- [Joel] - I guess there's like a few different approaches. One is to include in the message that's being signed a revocation registry. With us at Ceramic, in the stream there can be an 'everything is valid except these specific CACAO objects'. You need to specify some place where you can see if it has been revoked.
- [Wayne] - In fact you can use a Ceramic string to represent a revocation list. Where we would have to figure it out - would it be in the resources of SIWE.
- [Joel] - One approach is to have a specific URI that tells the capability that this is a revocation registry or another approach is in the resource itself, specify some parameter.
- [Wayne] - I wonder if in an ENS profile you can have the revocation list.
- [Joel] - One thing that's really cool is if you had data on Ceramic, it can be accessed by multiple different apps. If you as a user want to see who wrote to your data object, you can see which dapps specifically did it. You can have more attribution based on HTTPS sessions in browsers.
- [Ayori] - Can you comment on escalation of privilege and the process for detecting or preventing that. Like if something requested additional access in an app.
- [Joel] - I think it depends a little bit on how you design your dapp. If you have a completely decentralized dapp where the frontend is on IPFS and you have an ENS domain that points to that hash, then you can be pretty sure a malicious party can modify it. If however you're hosting on traditional DNS and have a server and backend --- the main kind of problem is: can an application trick the user to give more access to resources. That's something we as a community over time have to think about how we can provide tools to check the SIWE message.
- [Rocco] - Yeah and this is why wallets are required to show those resources to users so hopefully they're able to create interfaces like that.
- [Juan] - Can it work like a VC using the resource. It was just a simple comment - when we're talking about revoking in ceramic, it could work like a verifiable credential. You see the resource is a URL that would have a VC and see if it has expired or if it has been revoked.
- [Joel] - So the resource specified in the CACAO object is that this session key gets access to this resource. This might be around updating it for a certain amount of time. The other thing is how do we prematurely revoke it with some kind of registry where a user can check if it has been revoked. In VC world we have a concept of a revocation registry where you can check that.
- [Juan] - Thank you!
- [Joel] - I don't know if there's a standard practice, or know if folks have opinions on how to do it in a good way.
- [Haardik] - Re: expiration dates aren't required in SIWE, but assuming developers are using Ceramic's tools, we have a default expiration and we highly encourage it. It's not a defined property in SIWE.
- [Joel] - One thing that would be nice in SIWE in wallets, maybe there should be a warning for users when it comes to expiration dates. Like an interface for that to warn users.