Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pre-Draft: Browser-Session Data Model #170

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
+88 −0
Draft

Pre-Draft: Browser-Session Data Model #170

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
88 changes: 88 additions & 0 deletions caip-XX.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,88 @@
---
caip: <to be assigned>
title: Browser Session Token Model
author: <a list of the author's or authors' name(s) and/or username(s), or name(s) and email(s), e.g. (use with the parentheses or triangular brackets): Olaf Tomalski (@ritave), Hassan BM (@hbm-88), and Juan Caballero (@bumblefudge)
discussions-to: <URL>
status: Draft
type: Standard
created: 2022-11-08
updated: 2022-11-08
requires (*optional): <CAIP number(s)>
replaces (*optional): <CAIP number(s)>
---

<!--You can leave these HTML comments in your merged EIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new EIPs. Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. The title should be 44 characters or less.-->

## Simple Summary
<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the CAIP.-->
This data model proposes a minimal set of properties that structure a browser-based wallet<>dapp session for interoperability and security purposes.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It probably makes sense to define this as a protocol so security of the session can be analyzed more easily rather than a data model.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean CAIP-25 is the protocol and this is just a list of properties that can be sent back and forth between the two parties? Or do you mean something more complex than that?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm thinking that what we're defining here is an protocol to establish a wallet<>dapp session and we do this by using this API interface. Seeing how the choice of a "data model" has taken the VC spec down weird roads has made me realize that data model specs typically aren't defining enough to lead to interoperable designs where as protocols can. I believe this is also why some companies have strategically objected whenever protocols were going to be brought in scope.


## Abstract
<!--A short (~200 word) description of the technical issue being addressed.-->
In order to have common security assumptions about wallet<>dapp transport across browser-based cryptocurrency wallets and native application cryptocurrency wallets, it is helpful for browser-dapp sessions be able to express sessions in a simple, shared data model.

## Motivation
<!--The motivation is critical for CAIP. It should clearly explain why the state of the art is inadequate to address the problem that the CAIP solves. CAIP submissions without sufficient motivation may be rejected outright.-->
Wallet<>dapp sessions have historically been structured on an ad hoc basis but aligning feature discovery and other protocols benefits from negotiating these in an explicit manner such that further negotations can refer back to them.

## Specification
<!--The technical specification should describe the standard in detail. The specification should be detailed enough to allow competing, interoperable implementations. -->
NOTE: the following is a very naïve straw man proposed for discussion purposes by a dog in a trenchcoat. Comments follow each data model property

ASSUMING we can hold very close to the IPLD-based-yet-JSON-friendly schema syntax of CACAOs and define the session object as a simple subset of the CACAO data model, we could start from this straw man to define the session object

```
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not looking at the content, just straight up transcription.

type Header = { t: string };
type Payload = {
  domain: string;
  iss: string;
  aud: string;
  version: string;
  nonce: string;
  iat: string;
  nbf?: string;
  exp?: string;
  statement?: string;
  requestId?: string;
  resources?: string[]; // assuming this is an array of strings, instead of array with one element with type string
};
type Signature = {
  t: string;
  m?: SignatureMeta;
  s: ArrayBuffer;
};
type SignatureMeta = {};

type Header struct {
t String // when this CAIP goes to final status it could just be caipXX, right?
}
type Payload struct {
domain String
iss String // is it worth identifying the provider here, or some other actor in the browser by DOM path???
aud String // = uri --> this would go into the CAIP-25 req and response
version String // not sure if this is needed or just leaks metadata for fingerprinting wallets...
nonce String // remove?
iat String // RFC3339 date-time =issued-at
nbf optional String // RFC3339 date-time = not-before //make mandatory?
exp optional String // RFC3339 date-time = expiration-time //make mandatory?
statement optional String // remove?
requestId optional String // remove?
resources optional [ String ] // remove?
}

//would the browser-wallet (or... the snap?!) have a way to sign/own these, or are they just unsigned blobs floating in the DOM?
type Signature struct {
t String
m optional SignatureMeta
s Bytes
}

type SignatureMeta struct {
}
```
TODO - describe how to compact and stringify the above; I guess the
serialization depends on the desired interop targets, but if unsigned maybe just
JCS+base64 and call it a day?

## Rationale
<!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
TODO - MM team? Speaking of interop targets, maybe describe those a bit here and reference CACAO (caip-74) if it's a pertinent one?

## Backwards Compatibility
<!--All CAIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The CAIP must explain how the author proposes to deal with these incompatibilities. CAIP submissions without a sufficient backwards compatibility treatise may be rejected outright.-->
TODO - I'm hoping a browser expert/historian can speak to the overlap between this an classic web app session assumptions in the browser security model...

## Test Cases
<!--Please add test cases here if applicable.-->
TODO - MM team?

## Links
<!--Links to external resources that help understanding the CAIP better. This can e.g. be links to existing implementations.-->
Links to external resources that help understanding the CAIP better. This can e.g. be links to existing implementations.

- [RFC 3339][] - date-time standard used for expressing times

[RFC 3339]: https://datatracker.ietf.org/doc/html/rfc3339#section-5.6


## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).