new message-base description. #9
Conversation
fixed a typo; readability formatting; changed single quote mark to double (to be consistent with JSON spec, JWT spec, and this repo)
| Example: | ||
| ```JSON | ||
| { | ||
| "@type": "example.com/basemessage", |
There was a problem hiding this comment.
Maybe @type should be registered as a "public claim name" https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32#section-4.2?
| ### Applicable JWT attributes | ||
|
|
||
| * **"iss"** (Issuer) - from DID | ||
| * **"sub"** (Subject) |
There was a problem hiding this comment.
JWT presents itself as "a compact, URL-safe means of representing claims to be transferred between two parties." For that reason, it makes sense that it has these common "claim names". However, these claim names assume the signing algorithm is a very simple one, like RSA, DSA, or ECDSA. More advanced ZK signing algorithms are clearly not contemplated. The JWT spec has one paragraph on privacy, and it has two options (1) encryption, and (2) don't include information. Correlation privacy isn't mentioned.
If we say we're using JWT, it will be understood that we're using it for claims exchange, which we can't. We can use JWS and JWE as "dumb" wrappers, but the main purpose of JWT will be lost on Sovrin. We could take the portions of JWT that don't hurt correlation privacy and use just those, but I suspect others in the SSI ecosystem will want to use "iss", "sub", etc.
|
|
||
| Each message should have a type, specified by the top level @type attribute. The attribute value should be a URI that uniquely identifies the message type, and should be resolvable into a resource (ie, webpage) with details for message type use. | ||
|
|
||
| Each type indicates a particular version and format. |
There was a problem hiding this comment.
By format, do you mean JSON or YAML or MsgPack? I don't think we want to bind a type to a format do we. We'd end up with a cartesian product of two different concerns. Format can be handled generically and at a different layer than the domain-specific logic in a message handler.
There was a problem hiding this comment.
I mean the contents of the message attributes. At this point, the outer envelope would be a consistent format: json, encoded with whatever we decide should be standard.
|
|
||
| ```JSON | ||
| { | ||
| "@type": "example.com/examplemessage/v1" |
There was a problem hiding this comment.
This should be flexible enough to reference a web address as well as a blockchain schema address. Perhaps this should be a URI with a couple of examples, one web, and one blockchain?
|
|
||
| ## Message Encoding | ||
|
|
||
| Messages can arrive encoded and packaged in several different formats as described here. It is up to the agent to decide if and how to handle these various forms depending on the security requirements and considering the required uses. |
There was a problem hiding this comment.
How does the agent know the encoding and formatting? How does the agent know when it gets a blob of bits, what it is?
| ### Full Encryption | ||
| Messages will full encryption are packaged as described in this document. | ||
| ### Common Crypto | ||
| Messages are encrypted or signed using only commonly available crypto libraries. The security may not be as good as Full Encryption, but allows integration with limited systems. This serves both Enterprise Integration and advanced IOT applications. |
There was a problem hiding this comment.
What do you mean by "Full Encryption"? Is libsodium considered a commonly available crypto library?
| ### Topical Messages | ||
| Messages are usually part of interactions. | ||
|
|
||
| > TODO: How does this fit in with the JWT headers? |
There was a problem hiding this comment.
Because JWT is designed for claims, and is not a general message protocol, it's "sub" (subject) claim identifies who/what the claim is about. When the message isn't a claim, but a typed message in a protocol, then the topic makes more sense. The closest thing to JWT of a topic is the "jti" (JWT ID). Perhaps the "jti" could be co-opted for the tid, mid, and lmid, like this:
"jti": { "tid": "1", "mid": "1", "ptid": null, "lmid": 0}
or in a more compact way like this:
"jti": "1;1;;0"
|
|
||
| ## Base Envelope | ||
|
|
||
| The base message format is a JWT Payload. All JWT standard attributes are reserved. Additional attributes to messages are included based on the type specified. (See Message Types.) |
There was a problem hiding this comment.
I've been thinking about this a bit... The more I think, the more I'm concerned about JWT for a generic message system. I think it's fine for claims and claim sets (in use cases where correlation isn't an issue), because that's what it was designed for.
I see two different (orthogonal?) needs: (1) a general purpose message packaging protocol with types, wrapping, encryption, authentication, sub-protocol support (topics, sequencing, nesting) etc., and (2) a schema and standard for credentials (claims). JWT is the latter, with some encryption and signing on top.
I think a messaging protocol that is "inspired by JWT" is more of what we need for general purpose messaging. Just thinking out loud...
There was a problem hiding this comment.
This is what I like too, and how I suspect we will land. "Inspired by JWT" is good language. Another benefit of naming it something else is that we can avoid the confusion between JWT as claim transfer and JWT as message format.
There was a problem hiding this comment.
This is our opportunity to steer things here. If we can decide what we like about JWTs and what we don't, future conversations will be much easier and much more fruitful.
No description provided.