owned this note   changed 4 years ago  
Published Linked with GitHub

DIDComm spec assumptions

JOSE assumptions for DIDComm lib v0.1

JSON Serialization Syntax

  • JWE - General Serialization only
  • JWS
    • General for JWS Signed DIDComm Messaged
    • Flattened for jws attachment

ECDH-1PU

  • apu is same as in DIDComm Spec
  • apv is same as in DIDComm Spec
  • skid is same as in DIDComm Spec
  • only one sender key:
    • one value in skid/apu
    • one epk value in protected header for all recipients

ECDH-ES

  • Only one epk in protected header for all recipients
  • apv in protected header
  • apv is same as in ECDH-1PU
  • apu is empty (must not present in protected header at all)

Common

  • kid MUST be presented in JWE Per-Recipient Unprotected Header
  • kid MUST be presented in JWS Per-Signature Unprotected Header
  • aad is base64Url(protected_header)
  • Only one and the same alg in protected header for all recipients
  • skid and kid are UTF8 string

Forward

  • alternative endpoint:
    • how it works actually:
      • we have mediator's MEDIATOR_DID in serviceEndpoint in a recipient's DID Doc Service (DIDCommMessaging)
      • we resolve mediator's DID Doc (so we know its keyAgreement keys for anoncrypt)
      • we put its DID (the original one from recipient's serviceEndpoint) at the beginning of routingKeys so the mediator would be the first who receives the message and the last (top, outermost) in the forward envelops onion
        • divergences with the spec:
          • we don't put all keyAgreement into routingKeys
          • we put at the beginning (not at end)
      • then we can start just usual forward wrapping process
Select a repo