OOB / DIDExchange issue tracker

[TimoGlastra]

Tasks left from PR review:

• [x] Reuse oob invitation keys also for multiuse invitation (?)
  • @TimoGlastra Currently, I'm still creating new keys when it's multiuse invitation. I assume we don't want to do that, right?
• [x] Add oob record state and role checks
• [ ] feat(api): store more from receiveInvitation config into a record and allow override in acceptInvitation
• [ ] refactor(core): Change did to unqualifiedSovDid or maybe unqualifiedIndyDid
• [ ] refactor(core): Extract connection protocol methods from service to protocol class
• [ ] Throw an error if there is more then one rule resolved by state machine
  • But I actually didn’t find beneficial the way how I implemented the did exchange state machine
• [ ] Fix naming caused by DecryptedMessageContext vs. UnpackedMessageContext
• 🚧 OOB state should be set to done once we send or receive the first non-oob message (so after sending or receiving the didexchange / connection request message)
  • Currently done in response / complete handlers
• [x] Store legacy did and did document string in did record after converting to new did document (needs changes from https://github.com/hyperledger/aries-framework-javascript/pull/731)
• [x] We can probably remove some props from the connection record over time? E.g. multiUseInvitation (in oob record) and mediatorId (in oob record)
• [x] associating out of band recor with session and finding it based on that can maybe be insecure, as there's multiple entities that can act on the same oob record when using multi use invitations. Is this true?
• [ ] differentiate between stored and resolved version of peer did document
• [x] demo is broken (https://github.com/hyperledger/aries-framework-javascript/pull/779)
• 🚧 connectionless should be integrated with oob, also we should allow for connection reuse when doing connectionless. the oob offer/request will not have a connection id when we receive the first reply. we must set it on the record
• [x] creating an out of band offer/request will currently create keys, and the oob invitation will also create keys. I propose the following flow:
  1. create oob offer/request no keys will be created, no ~service is present
  2. call oob.createInvitation to create oob invitation containing the offer/request
  3. OR call oob.createLegacyConnectionlessInvitation (naming not final yet, but you get the idea) that will generate a key and set the ~service decorator. This makes the process two steps, but I think the api is nice enough to do that.
• [ ] rename outOfBand to outOfBandRecord
• [ ] Think of ways to not require ConnectionsModule. acceptOutOfBandInvitation to be public
• [ ] support other numAlgo than did:peer method 2 / figure out what to do with dids without a did document (https://github.com/hyperledger/aries-rfcs/issues/717) -- only if key rotation is used
• [x] connectionRecord.threadId = message.threadId || message.id (message.id is redundant)
• [ ] Change the defaults of autoAcceptConnection and autoAcceptInvitation?
• [ ] Update connection complete listener to event listener so it survives agent shutdown
• [ ] resolveDidDocument vs resolve in dids module
• [ ] use ReferencedAuthentication instead of embeddedAuthentication (@jakubkoci specific reason you changed this?) we now include the same key object twice which I'm not sure if that's allowed
• [x] oob.test.ts use event listener instead of while loop to get all credentials (https://github.com/hyperledger/aries-framework-javascript/pull/778)
• [x] fix the test packages/core/src/utils/tests/JsonTransformer.test.ts
• [ ] remove dupilcates from recipientKeyFingerprints
• [x] oob record did value is not always a qualified did
• 🚧 integrate connectionless with oob
• [ ] integrate ppv2 with createLegacyConnectionlessInvitation (will do so once ppv2 has been merged)
• [ ] remove old tags in migration script
• [ ] add unit tests for didexchange protocol
• [ ] check all todos in code comments
• [x] createLegacyInvitation should not allow all parameters from createInvitation with oob
• [ ] passing mediatorId when creating invitation is too complex (need to call getRouting first?)
• [x] receiveInvitation should accept a ConnectionInvitationMessage
• [ ] autoAcceptConnection should also be taken from the out of band record?