key agreement/authentication and interoperability

[wenjing]

This is a major feature improvement proposal about key agreement and interoperability offered by TSP.

1. TSP promises interoperability

TSP offers interoperability of trust primitives between different arrangements. For example, Alice may use a did:webvh identifier that she controls while Bob happens to use a did:web.

In Alice's did:webvh document, she may specify a list of acceptable keyAgreement schemes and a list of authentication keys. Same for Bob. But Alice's and Bob's options may be different. The identifier's owner specifies what she/he will accept, one or more, and the endpoint that sends Alice messages chooses which among the subset that they share. Alice offers options; Bob calculates the intersection of what he supports and what Alice accepts, and chooses one from that subset.

This selection scheme is processed for keyAgreement (DH) and for signature (authentication).

2. TSP SDK 0.9.1 however doesn't allow it because code is gated by compile time flags: #[cfg(feature = ...)]

To fix this problem, we need to restructure code to remove those flags and allow additive options. A developer can skip some options for reducing the size of the library, for example. But it needs to build with all options it intends to support.

We may need to look into a pluggable design with traits too if the overhead is not too big. That would be ideal. If not, then modify the flag to allow additive features. One may build without PQ (e.g.) but support all the rest of configurations and the interoperability among them.

3. VidEncryptionKeyType needs to record all supported options rather than just one right now - and have a logic to select among all advertised keyAgreement schemes.

Note: this may also need to reflected in the tsp spec itself. This needs to be coordinated.

4. Default

We also need to handle the case where the destination endpoint's DID document does not specify any in the keyAgreement field or authentication field. In that case, TSP should default to one.
Note: such behavior probably should also be in the spec itself.

The above is just a draft of what this feature needs. We may come back with more details or mods.