Support connection re-use for did:peer:2/4

[ianco]

See issue https://github.com/hyperledger/aries-cloudagent-python/issues/2703

This PR is WIP, reuse working for public DID and did:peer:2/4, still need to do additional testing and code cleanup.

• adds additional meta-data to the wallet DID, to flag a did:peer for re-using in invitations
• add the DID meta-data to the admin API GET /wallet/did response
• add a flag to the OOB create invitation to request a unique did (default is to re-use the invitation DID in the wallet)
• reuse works for did:peer:2 and did:peer:4, and also public DID
  • should this be generic? and how to determine if the DID can be used for connection reuse? should it work for ALL DID methods? ***
• added separate flags to the demo for:
  • --public-did-connections - use the inviter's public DID in invitations, and allow use of implicit invitations
  • --reuse-connections - support connection re-use (invitee will reuse an existing connection if it uses the same DID as in the new invitation)
  • --multi-use-invitations - inviter will issue multi-use invitations
  • note that the --reuse-connections flag needs to be enabled in both Faber and Alice for the demo to enable connection reuse

*** see questions above

[swcurran]

My thoughts on the questions:

reuse works for did:peer:2 and did:peer:4, and also public DID should this be generic? and how to determine if the DID can be used for connection reuse? should it work for ALL DID methods?

The requirement for reuse in the spec. is that the service item in the invitation be a DID -- not a JSON structure such as happens with an unqualified DID (what we've mostly used to now) or a did:peer:1. As we are dropping support for either of those, likely any DID is valid -- since the DID is resolved. did:peer:2/4 are magic in that by "resolving" them, the DIDDoc (the data that would be in the JSON structure) is decoded. Note that did:key is not permitted as it does not have an endpoint to which messages can be sent.

Does that help?

adds additional meta-data to the wallet DID, to flag a did:peer for re-using in invitations

Perhaps this should also allow flagging ledger-based (published/public) DIDs? E.g. any DID that supports "resuse"?

add the DID meta-data to the admin API GET /wallet/did response

Sounds necessary to me.

[amanji]

Is there any way we can pull out the create methods for did:peer:2/4 into a separate but mergeable PR?. It would be useful to have for integration testing, but I can also patch in the change from this PR.

[ianco]

adds additional meta-data to the wallet DID, to flag a did:peer for re-using in invitations

Perhaps this should also allow flagging ledger-based (published/public) DIDs? E.g. any DID that supports "resuse"?

It's already used for flagging public DID's, so I'm just piggybacking on an existing feature.

[ianco]

The requirement for reuse in the spec. is that the service item in the invitation be a DID -- not a JSON structure such as happens with an unqualified DID

OK this is clear, I'll update to check for a DID, and remove the specific did_peer checks that I added

[ianco]

For did:peer:4 should the connection use the long form or short form of the did?

      "my_did": "did:peer:4zQmbCiTt4dS2XZz9BMGYpZTKH92mYzq9Q1cavQPtfrFEfiV",
      "their_did": "did:peer:4zQmUpGK93RFrakSGmJbwL9QJXqs4uC2S8NQeSyzcomCqKzz",

vs ...

    "my_did": "did:peer:4zQmbCiTt4dS2XZz9BMGYpZTKH92mYzq9Q1cavQPtfrFEfiV:zCo9LoqasV3ZFnxnYNDU8yhBL9F6kGgrTrneiFJHM5Z8L7jw9Gj3H61gCqSKjiMxqWzztJykZfSAM5AXaeyD6wtFwjgyoPMZ6EYSoJ2HwFRd4oafTXtCvGmTC8E4FpjcFaQgnbe1uVbtRmZ1q96mPeMwsDszPiKuyH5D9rHULHkETFwd9hjPKSroX9XVoNxRaprNVr9JLWproTuDzCFwrRYou24dwVAUSsVtnM1ti2PJuZk3D5sdYqDeL8y4yw7WwVvzqd9jykuCt9nQyPBE2DE6saLSAyJRY3tYin2kcdeLCgWJfmaubDVqaEKQnFLZFJodbuts52PHhKGKcgoVXu4nKowE6zedeVtTmZEjn4USXg3oePgnQ47wDbFC5Z1nQgkZG3o7HtWWxmpYZQGqxxZxNDYckfLVxyAdNGZcXN2uHd6i788bc5B5tEEmBptAr9BeaggjobsZanaMDxNHkMLTHbVpn199pNwYXLwpZR8mdB4WMk99FQHyziWHbBLLUihEJqJzsdX88v8",
      "their_did": "did:peer:4zQmUwLj6dLCg2Sv9YirbFkzwFaMyRvmoqSn5Pge9fdP9ATi:zCo9LoqasV3ZFnxnYNDU8yhBL9F6kGgrTrneiFJHM5Z8L7jw9Gj3H61gCqSKjiMxqWzztJykZfSAM5AXaeyD6wtFwjgyoPMZ6EYSoJ2HwFRd4oafTXtCvGmTC8E4FpjcFaQgnbe1uVbtRmZ1q96mPeMwsDszPiKuyH5D9rHULHkETFwd9hjPKSroX9XVoNxRaprNVr9JLWproTuDzCFwrRYou24dwVAUSsVtnM1qintrVJ618X7sPxk13tCXhXHsMUHxK7PeL8sZG8dUFpc75k5waWuCTWK7gQhpvBGoijh4JCZMbqhFWGqUEwRZ3UbgC5f2DWM1MDJFbVtWmgkWtjtiEcJ1366gsLPRpuLYjPfAbMGRD6fXhFLaAmAxJjkEKpR4SvHUucdzv1LYeUZT6dMxf15dY5of2ca8YYSeGdpWYxrfpeMDkkfCSqXbTvXd8opaDEWjdmYMUnQVDBiWiW7C1cuPs73ewcCaeJP11yUbgD24qNtZZFLziaz3XoGRc5N1UfJ6HmCUKTi",

[swcurran]

@dbluhm and @TelegramSam — can you please weigh in on this one to help Ian complete the implementation? Thanks!

[dbluhm]

For did:peer:4 should the connection use the long form or short form of the did?

I'd say short form unless there's a strong reason not to (there isn't an obvious reason that comes to mind for me).

[dbluhm]

10 minute scan didn't reveal any red flags for me. I'll have to set aside some time to look deeper.

[ianco]

Integration tests have failed twice in a row, so I ran them locally and everything passed.

[sonarqubecloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud