Skip to content
This repository has been archived by the owner on Jun 13, 2023. It is now read-only.

need tests for DID Exchange / Connection Protocol #3

Open
dhh1128 opened this issue Sep 11, 2019 · 5 comments
Open

need tests for DID Exchange / Connection Protocol #3

dhh1128 opened this issue Sep 11, 2019 · 5 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@dhh1128
Copy link

dhh1128 commented Sep 11, 2019

All of the following tests are needed.

  • An overly long invitation is rejected since it can't be turned into a QR code?
  • Agent can be either inviter or invitee.
  • A public DID can be used as an implicit invitation.
  • A connection resp that is not signed by the key used in the invitation generates a graceful error.
  • A connection resp sent before a connection req generates a graceful error.
  • A connection resp or connection req that uses a different thread from the previous message generates a graceful error.
  • A connection resp or req that uses the same thread as previous, but an inconsistent state (e.g., different DID Doc or endpoint) is rejected.
  • DID Docs with extra fields are handled.
  • DID Docs lacking required fields are rejected.
  • DID Docs lacking public keys of type {Ed25519|Secp256k1|RSA} are either handled fully, or generate a graceful error.
  • A plaintext version of a connection request or connection response is gracefully rejected.
@dhh1128 dhh1128 added enhancement New feature or request good first issue Good for newcomers labels Sep 11, 2019
@dbluhm
Copy link
Contributor

dbluhm commented Nov 19, 2019

Progress:

  • An overly long invitation is rejected since it can't be turned into a QR code?
  • Agent can be either inviter or invitee.
  • A public DID can be used as an implicit invitation.
  • A connection resp that is not signed by the key used in the invitation generates a graceful error.
  • A connection resp sent before a connection req generates a graceful error.
  • A connection resp or connection req that uses a different thread from the previous message generates a graceful error.
  • A connection resp or req that uses the same thread as previous, but an inconsistent state (e.g., different DID Doc or endpoint) is rejected.
  • DID Docs with extra fields are handled.
  • DID Docs lacking required fields are rejected.
  • DID Docs lacking public keys of type {Ed25519|Secp256k1|RSA} are either handled fully, or generate a graceful error.
  • A plaintext version of a connection request or connection response is gracefully rejected.

@dbluhm
Copy link
Contributor

dbluhm commented Nov 19, 2019

A plaintext version of a connection request or connection response is gracefully rejected.

What would we consider a graceful rejection in this context? A 400?

@dhh1128
Copy link
Author

dhh1128 commented Nov 19, 2019

The condition that's triggering a graceful rejection is that the message trust context doesn't confer enough trust to proceed. I would expect a graceful rejection to be a problem report explaining that.

@dbluhm
Copy link
Contributor

dbluhm commented Nov 19, 2019

Given that there are no keys to figure out which connection sent the message, would we expect this message to be returned in plaintext to the active http connection?

@dhh1128
Copy link
Author

dhh1128 commented Nov 20, 2019

Actually, now that you point out that detail, I would be content with a 400

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request good first issue Good for newcomers
Development

No branches or pull requests

2 participants