Explain profiles #177
Explain profiles #177
Conversation
Signed-off-by: Daniel Hardman <daniel.hardman@sicpa.com>
|
@TelegramSam and @troyronda: I don't know if this is the right place to put this content, and I also don't know how much what I added here overlaps with what Troy will write. But here's a quick attempt to capture what we discussed on the call today. To be refined and/or replaced with something better... |
docs/spec-files/message_structure.md
Outdated
| ### Defined Profiles | ||
|
|
||
| * `didcomm/aip1`: The encryption envelope, signing mechanism, plaintext conventions, and routing algorithms embodied in Aries AIP 1.0, circa 2020. | ||
| * `didcomm/aip2`: The encryption envelope, signing mechanism, plaintext conventions, and routing algorithms embodied in Aries AIP 2.0, circa 2020. |
There was a problem hiding this comment.
There are actually two flavors of AIP2 - one with Envelope v1 (RFC 19) and one with Envelope v2 (RFC 587).
Currently the media types in the Aries accept properties are:
- application/json;flavor=didcomm-msg (roughly the equivalent of AIP1).
- application/didcomm-encrypted+json;cty=application/json (roughly the equivalent of AIP2 with Envelope v2).
With AIP2 + Envelope v2, we are allowing an AIP to enable community transition with an AIP2 target. If we could include that target concept here, then we could propose the same profile media type concept in Aries RFCs.
There was a problem hiding this comment.
Agreed. Good point.
What if we did the following:
didcomm/aip1: (no change in descrip)didcomm/aip2retro: The signing mechanism, plaintext conventions, and routing algorithms embodied in Aries AIP 2.0, circa 2020 -- with the old-style encryption envelope from Aries RFC 0019. This legal variant of AIP 2.0 minimizes differences with codebases that shipped AIP 1.0 support.didcomm/aip2pro: The signing mechanism, plaintext conventions, and routing algorithms embodied in Aries AIP 2.0, circa 2020 -- with the new-style encryption envelope from Aries RFC 0587. This legal variant of AIP 2.0 lays the foundation for DIDComm v2 support by anticipating the eventual envelope change.didcomm/v2(keep current description)
There was a problem hiding this comment.
Thanks @dhh1128 - nice writeup.
There was a problem hiding this comment.
I've updated the text to address this point. What do you think, @troyronda ?
Signed-off-by: Daniel Hardman <daniel.hardman@sicpa.com>
docs/spec-files/message_structure.md
Outdated
| 2. The key types used for encryption and/or signing | ||
| 3. The format of the encryption and/or signing envelopes | ||
| 4. The encoding of plaintext messages | ||
| 5. The protocol used to forward forward and route |
There was a problem hiding this comment.
Good catch. Updated.
Signed-off-by: Daniel Hardman daniel.hardman@sicpa.com