- Author: Daniel Hardman
- Start Date: 2018-05-17
- Status: SUPERSEDED
- Status Date: 2019-01-15
- Status Note: We implemented a different version of the test suite
interface in early 2019. That version is now (June 2019) in the
indy-agent
repo--but the whole repo is being superseded by an Aries repo instead.
Defines the content and implementation of a test suite that evaluates interoperability of Indy agents.
This is a test suite content HIPE. It is intended to satisfy the common behavioral contract defined in a seprate test suite interface HIPE. (These two types of spec are divided so they can be versioned and standardized separately.)
What follows is a list of tests, organized into feature clusters, to exercise the interoperability of agents. Each test has a canonical name and a description that describes how an agent passes the test.
This is the most basic feature cluster in the test suite; it tests that agents listening passively understand messages that they receive, and that they respond in expected ways.
Upon receiving an auth_crypt'ed message of type agent-metadata-request
../agent-test-suite-interface/README.md#agent-metadata-request, where
the type of requested metadata is an interop profile
and the URI of the interop profile is the URI of this HIPE,
reply with a valid interop profile.
(Should we have an anon_crypt'ed variant of this test? Different agents may make different decisions about whether to report interop to anonymous versus authenticated parties...)(Should we topicalize the metadata request, and then test topicalized response?)
Upon receiving a [message of type agent-metadata-request
, where the
type of requested metadata is an interop profile and the URI of
the interop profile is http://example.com/no-such-URI
,
reply with an empty interop profile, indicating that the agent
provides nothing but divergence from any test suite at that URI.
Upon receiving a message of an unrecognized type, reply with a graceful error using error code E_UNRECOGNIZED_MESSAGE_TYPE.
Upon receiving a message of type trust-ping
, reply with a message of
type trust-ping-response
.
Test fixture sends setup instructions over the agact
backchannel
that look like this:
{
"on-next-message": [
{"connection-request": "accept"}
]
}
This tells the agent to accept the next connection request--or to at least pretend to, for the purpose of the test.
Once preconfigured in this way, upon receiving an anon_crypt'ed message of
type connection-request
, reply with a message of type connection-accepted
.
Test fixture sends setup instructions over the agact
backchannel
that look like this:
{
"on-next-message": [
{"connection-request": "accept"}
]
}
Once setup, upon receiving an anon_crypt'ed message of type connection-request
,
reply with a message of type connection-rejected
.
(Send a connection request that's redundant because we already have a connection to the requesting party. Do we need this? If so, what should be the defined behavior?)
Send a trust ping that's anon_encrypt'ed.
Send a trust ping that's auth_encrypt'ed.
Send a connection request.
Send an interop request for this test suite.
This suite probably has to be subdivided by role (issuer, holder), and by active vs. passive.
Offer a credential that has no price.
Issue a credential that has no price.
Refuse to issue a credential because requester doesn't prove correctness (tries to embed data that issuer doesn't want to allow).
Refuse to issue a credential because requester hasn't paid for it.
Provide a correct cred request to enable issuance.
Dicker on price of issued credentials.
Dicker on terms of credential use.
Dicker on content of offered credential.
This suite probably has to be subdivided by role (prover, verifier), and by active vs. passive.
Present a proof that doesn't match the requested criteria.
As verifier, ask for proof that's reasonable, that the prover can satisfy.
As verifier, ask for proof that's unreasonable, that the prover can't satisfy.
Why should we not do this?
- Why is this design the best in the space of possible designs?
- What other designs have been considered and what is the rationale for not choosing them?
- What is the impact of not doing this?
Discuss prior art, both the good and the bad, in relation to this proposal. A few examples of what this can include are:
- Does this feature exist in other SSI ecosystems and what experience have their community had?
- For other teams: What lessons can we learn from other attempts?
- Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background.
This section is intended to encourage you as an author to think about the lessons from other implementers, provide readers of your HIPE with a fuller picture. If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if it is an adaptation from other languages.
Note that while precedent set by other ecosystems is some motivation, it does not on its own motivate an HIPE. Please also take into consideration that Indy sometimes intentionally diverges from common identity features.
- What parts of the design do you expect to resolve through the HIPE process before this gets merged?
- What parts of the design do you expect to resolve through the implementation of this feature before stabilization?
- What related issues do you consider out of scope for this HIPE that could be addressed in the future independently of the solution that comes out of this HIPE?