-
Notifications
You must be signed in to change notification settings - Fork 150
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.
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
base: main
Are you sure you want to change the base?
Conversation
|
||
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 | ||
|
||
``` |
There was a problem hiding this comment.
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 = {};
|
||
## 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
No description provided.