search

tdiesler / nessus-didcomm

Nessus DIDComm is about Digital Identity and Verifiable Credentials
Apache License 2.0
8 stars 1 forks source link

Failure to route without Message.to header #127

Closed tdiesler closed 1 year ago

tdiesler commented 1 year ago 
If I try to send it without the router wrapper I get 
'{"msg":"No target did","trace":"java.lang.IllegalStateException: No target did"}'
tdiesler commented 1 year ago

Not sure how the dispatcher is supposed to work without to and from. The sicpa library provides an UnpackResult with ...

encryptedTo=did:peer:2.Ez6LSsYLxdDAbZDrBs8rPxxh5yMBRFVqArfhsSBBqxXmcBCQU.Vz6MkjyGdybk4M8W59KsmStrf32Q1JZfsL521E6MaZ7qnmyom.SeyJ0IjoiZG0iLCJzIjoiaHR0cDovL2xvY2FsaG9zdDo5MDAwIn0#6LSsYLxdDAbZDrBs8rPxxh5yMBRFVqArfhsSBBqxXmcBCQU
_Message.to=did:peer:2.Ez6LSsYLxdDAbZDrBs8rPxxh5yMBRFVqArfhsSBBqxXmcBCQU.Vz6MkjyGdybk4M8W59KsmStrf32Q1JZfsL521E6MaZ7qnmyom.SeyJ0IjoiZG0iLCJzIjoiaHR0cDovL2xvY2FsaG9zdDo5MDAwIn0

____signFrom=did:peer:2.Ez6LSiWVFeDTzF8cp5WbdTjzQK2o8U9K2R8kzEwSbhJYUDEhH.Vz6MkiV6KXQC4sCgbrJ3uRctqC2zowqfaydc12Jas6StfWuT7.SeyJ0IjoiZG0iLCJzIjoiaHR0cDovL2xvY2FsaG9zdDo5MDAwIn0#6MkiV6KXQC4sCgbrJ3uRctqC2zowqfaydc12Jas6StfWuT7
Message.from=did:peer:2.Ez6LSiWVFeDTzF8cp5WbdTjzQK2o8U9K2R8kzEwSbhJYUDEhH.Vz6MkiV6KXQC4sCgbrJ3uRctqC2zowqfaydc12Jas6StfWuT7.SeyJ0IjoiZG0iLCJzIjoiaHR0cDovL2xvY2FsaG9zdDo5MDAwIn0

As you can see, the unpack results reference key ids (kids) into the DidDoc and not Did URIs. By convention these kids usually start with their respective Did URI, but that isn't required. In contrary, I found a section in the spec that explicitly states that a kid cannot be used to deduct anything. The only requirement is, that it is unique.

I could default to Message.to/from and fallback to these kids with the #... cut off. Thoughts?

tdiesler commented 1 year ago

The SecretResolverService does this

I have after all, a way to get from a kid to a did

tdiesler commented 1 year ago

For encrypted messages, you can omit to and from. For signed and plain messages, the routing info cannot be derived from the unpack results (i.e. this needs to be defined on the message)