Pickup Protocol 1.0, 2.0 and 3.0 #52
Conversation
| "return_route": "all" | ||
| } | ||
| ``` | ||
| `recipient_key` is optional. When specified, the `mediator` **MUST** only return status related to that recipient key. This allows the `recipient` to discover if any messages are in the queue that were sent to a specific key. You can find more details about `recipient_key` and how it's managed in [Mediator Coordination Protocol](). |
There was a problem hiding this comment.
We should probably think how to encode the recipient_keys. The v1 and v2 of this protocol use base58 encoded keys, but this carries the assumption that all keys are ed25519 keys. We need a more expressive way to encode keys. After that we switched to did:key encoded keys which is also not the ideal way to express keys IMO.
What if we start using publicKeyMultibase? E.g. the Ed25519Signature2020 suites uses this (https://w3c-ccg.github.io/lds-ed25519-2020/). It provides the public key and also the encoding + key type. Basically it's a did:key without the did:key part. We should probably look at limiting which bases to support: https://github.com/w3c-ccg/lds-ed25519-2020/issues/3
Kyle also mentioned that we could look at JWK encoding of keys: hyperledger/aries-rfcs#704 (comment). Also seems like a valid option to me, but more complex and not encodeable as a single string.
There was a problem hiding this comment.
Since DIDcomm v2 the forward messages now uses dids to forward messages. Should we start using DIDs instead of the keys? In that case we don't have to solve the encoding issues. This would also make key rotation easier and it probably makes sense to use dids in the DIDComm world.
https://identity.foundation/didcomm-messaging/spec/#messages
There was a problem hiding this comment.
Also see my comment on the mediator coordination protocol: https://github.com/decentralized-identity/didcomm.org/pull/50/files#r923169329
There was a problem hiding this comment.
Also see my comment on the mediator coordination protocol: https://github.com/decentralized-identity/didcomm.org/pull/50/files#r923169329
yes, we should match on what we define in the mediator coordination protocol. recipient-did makes a lot of sense
|
I think the conversation about key formats is important, and I would be happy to entertain a new PR that improves our descriptive text appropriately, as @TimoGlastra has suggested. However, I don't think we should hold up the initial merge while we wait for that; we want some documentation about this to exist asap. So I'm going to merge what we have right now. |
Add Pickup Protocol.
Please, give feedback on:
report-problemmessage. We need to define a code for that error likee.m.live-mode-not-supported