Notes for Editorial Meeting 25 Aug

[bumblefudge]

CASA Agenda 25Aug

PRs to refine/move to close

• Issues to discuss

  • ETH2.0 issues

    • For core CAIP-2 there's no influence because there's no description of time included in it; block=latest is as close as it comes to describing the time. For that we're not doing it, but this will likely move to just have a CAIP about block-number queries.
    • Oren: opened when it was very unclear how it would end up, now it would be one fork that changes the chain ID to a new number so it would be easy to follow and hopefully that would make things more clear but besides that I just wanted to see if there are any other thoughts on that.
    • Oren: Because there's no official leadership to the Proof of Work fork, things will get messy.
    • Rocco: So ETH2 will remain 1?
    • Oren: No replay attacks - things just fall into order. Now it seems there will be another fork and miners won't change the ChainID. Just wondering if there are ways to address Ethereum chains with potentially the same ChainID. Bitcoin vs Bitcoin Classic = take the genesis block hash, but with EIP-155 there isn't an easy way to track changes for the same chainID.
    • Ligi: We can also use the fork ID from 2124 - so there's a forkID in that EIP. We can use CAIP-2 but there might be duplication.
    • Next steps: review EIP-2124 / hold and wait on the merge to see if it will be a problem and if the fork gains traction.

  • IANA wen? Should we have a strawman for an IANA proposal to review at in-person event in Sept?

    • Ligi: Would be good to have Pedro in person to address this or create the strawman. Without him it's hard to move this forward - it would be a good opportunity. Could be an IANA breakout session - and it's good when it comes from an event.
    • Haardik: Does this break any code if we change this or references that we might be following (for example CACAO having a header of CAIP-122).
    • Ligi: The spec will be backwards compatible. This would just be a wrapper around this. There are some items from the amsterdam meeting notes - but we cannot break it now. It needs to be backwards compatible so let's not break it.

  • Expanding or finalizing CAIP-10

    • New CAIP, don't break the old one that can replace it in the end.
    • Tim: With the query parameters, we agreed in the last meeting in Berlin we'll have an in-person session and talk more about this specifically.

  • If around, Jared H proposal for Blockchain Claims for use in JWT

    • Jared: Some of this was inspired by the work via Sign-In with Ethereum or Sign-In with 'X', but that covers authentication only and this is inspired by OAuth and OpenID - after you authenticate them, you issue an artifact in the form of a token with signed statements about who authenticated. Really what this is trying to do: take the identifier formats that CASA has and define a standardized way to represent them in JWTs so APIs can be used and built in a relatively standardized way. That's the goal of what this proposal is doing. Would love any feedback, not sure if it should be here, IETF, OpenID, etc.
    • Haardik: Have you looked at CAIP-74? What we kind of do at Ceramic is delegating permissions to someone else through the resources of SIWx, which gets converted in a capability object and we use those resources as claims to let someone do something on someone else's behalf.
    • Jared: Is that the wallet owner authorizing access to these resources? [yes] - My mental translation would be consent in an OAuth style flow. It seems orthoganal to the JWTs - so take an offline use-case where you have off-chain APIs that need to understand who the user is. This information needs to be conveyed to those APIs which would be the purpose of the JWT.
    • Sergey: Mind if I ask -- is the hard requirement to have JWTs?
    • Jared: There's no hard requirement to use JWTs - now your second question, who is proving this stuff. Use case: OpenSea. If you think about their flow, you go there, you log in, then as you interact with that application, they're just making backend API calls to their own service. The idea with the JWT is that OpenSea or any other app can do the SIWx procedure, authenticate the wallet's signature and all the statements in this construct and turn around and issue their own JWT to capture that information so it can be sent to their own APIs.
    • Sergey: Got it - so basically trust is implicitly involved.
    • Jared: Yes - there's trust between the issuer of the JWT and the party accepting it.
    • Sergey: Why would you need the JWT at all?
    • Jared: You need some kind of token to sign and verify, there's also just a bunch of proprietary ones - this would just be a way to construct it. Only talking JWTs at least in our case with Okta and Auth0 - we run servers that authenticate people and then we issue tokens consumed by other software that isn't us. JWTs is just the current best practice around a standardized token format.
    • Haardik: Why not a chain of capabilities?
    • Jared: It could potentially be done that way - would love to understand how that would be an alternative.
    • Haardik: Chain of capabilities: the original wallet owner authorizes access to certain things - let's say 5 resources. You can take them and furhter authorize 3 of them to Sergey, who can then authorize 1 to Ligi and you can see the entire verified history of these capabilities.
    • Jared: Fair enough, it's probably very related and can solve similar use-cases. Just on my impressions - I feel like it's a different use-case. Think about the developers implementing the OpenSea API on the backend - they already trust OpenSea's auth of a particular user.
    • Rocco: Both rely on different trust models which is the core basics of this.
    • Haardik: Not opposed to it, just trying to understand what's going on. Question - have you looked into oauthxyz - can that help with anything here?
    • Jared: OAuthxyz is what evolved into GNAP - it has been a while since I dug into it completely. My impression of that: it was another equivalent to OAuth2 with different serialization and capabilities, but the end result of it was the issuance of tokens which had an implicit trust model. They did have some notion of DIDs as an identifier as a protocol, which could be an alternative. In this case you can use DIDs instead of CAIP identifiers.
    • Sergey: It seems like we would have to provide all the tooling for CACAOs to handle that properly. For this scenario to make it as easy as JWTs with that security model - but with full provenance, we'd need to work more on CACAOs. But it's like lots of work.
    • Jared: I would love to ping you guys async and get more information. I'm coming at this from a different knowledge base, but just my reading of the CACAO things - I couldn't parse how it would be familiar to someone with knowledge of JWTs.
    • Next steps: facilitate intro to Sergey / Haardik / Jared.

  • add caip122 spec for eip155 namespace

    • To approve / merge (done)

Misc. Items

• CASA Berlin gathering (any additional action items here)
  • Attendance is a bit low, so we're 25 or so. It would also be good to have a small group. I was expecting a larger group after Amsterdam - but we can prepare and invite more folks. Boris is going to also step in.