Using DIDSession with createDagJWE

Devtools Ceramic SDKs
1

Hey,

I’ve spent the weekend updating my app to use the DIDSession (vs old 3idConnect). First steps were easy, woot.

however I also use did.createDagJWE and it turns out that a DID from one session cannot decrypt a JWE from another session. Setting did.parent as a recipient is no good either as it’s an unsupportedDidMethod. Makes sense, as each sessions DID is actually unrelated.

Any suggestions how I can use both DIDSession & createDagJWE? Or should I just use a different method of encrypting my data?

1 Like
2

So my temp workaround:

I always have a signer, so I’m creating a temp DID using the following:

  const msg = await signer.signMessage("This gives permission to read or write profile data");

  const privateKey = fromString(msg.slice(2), 'base16')
  const oneOffDid = new DID({
    resolver: getResolver(),
    provider: new Ed25519Provider(privateKey.slice(0, 32)),
  })
  await oneOffDid.authenticate();
  return oneOffDid;

then creating the JWE with

  const oneOffDid = await getOneOffEncryptDid(client);
  const owners = new Set([oneOffDid.id, ...recipients])
  const encrypted = await oneOffDid.createDagJWE(clean, [...owners])

It’s bit of an icky workaround, but from the it-works viewpoint… well, it works.

Is there any obvious reason this is a terrible idea? The signature should have plenty of entropy, and worst-case scenario is an attacker gaining control of the signer (at which point it is pretty hard to mitigate)

2 Likes
3

This approach is reasonable and is what I’d suggest using. 3ID Connect (which is no longer actively supported) used a similar trick behind the scenes.

The only modification I’d propose for you is to use the hash of the signature (msg in your case) instead of the signature directly.

2 Likes