Trust Enablement Workflow using Trust Documents

While the ToIP Stack defines the overall stack and component organization, it lacks a workflow for establishing trust between two Parties using those components and the Trust Spanning Protocol

The Discussion presents an early draft of the workflow, which assumes the use of Layer 2 and 3 components (e.g. Wallets, Trust Registries), primarily in the Trust Evidence Request/Response interaction, but does not show that level of detail. 

Notes: 

• The Sequence chart only shows Trust Requests from Alice to Bob (for simplification), where in any Trust Exchange, the trust request/response/decision flow would be in both directions.  
• This illustration only shows a single set of trust requests (e.g. about the other Party's identifier, wallet or verifiable credentials), but any realistic Trust Establishment Workflow (Trust Ladder) would be a sequence of blocks of requests and decisions.
• The direction this concept is taking is already leveraging the "composable" principle, such that establishing trust is dynamically configurable from components and interactions.

Meeting notes (not in any particular order. They are comments about the behaviour of the system and the requirements/properties of the components)

Trust Evidence

Trust Evidence and the ecosystem system status (for both Parties and their ecosystems) need to be collected during interactions of any type, including pty2pty and any other ecosystem interaction

prty2pty evidence about infrastructure components as well as high trust entities (Issuers, Verifiers, etc.) need to be shared for use by other Parties and the Ecosystem in general

There is an issue with privacy and confidentiality about Entities: People, Organizations, and Devices(?). Trust Evidence, including Verifiable Credentials and custom presentation of claims, consent, etc., need to have lifetime restrictions.

The default is that while the purpose and status of a trust workflow eventual status (Party X, trusted for the following context/purpose) may be persisted (Party X Trust State by purpose/context) during the trust decision workflow, the actual evidence collected should be discarded (default) once the trust workflow is complete.

That trust may also require an explicit agreement on trust evidence retention such that the shared-to Party (Entity) agrees not to capture PII or other sensitive data through any means (e.g., notes made in a text file while interacting with another Party, screen/device recording, etc.)

Trust History may be different from the Trust Evidence Cache for simplification of persistent trust information (purpose & context by counterparty) or "trust evaluation only" information.

• In addition, with the final "trust state", it may be useful if Trust History is allowed to keep Trust Evidence as supplied by the counterparty as a hash of the Trust Document and/or some/critical TDoc content (with/without the proof block). This avoids the problem of the retention of sensitive/PII data but allows each party to detect changes in evidence that may be due to an impostor/bad actor.

Caching Evidence Decisions

There are at least two options for Trust Establishment Workflows

• Zero Trust Establishment Retention - No trust evidence nor trust outcomes are retained, and the entire trust establishment workflow must be re-established from no-trust for each independent interaction between two Parties (Zero Trust Establishment Workflow)
• Verifiable (?) Trust Establishment Decision Reuse - A Party can retain hashes of the TER evidence responses and the Trust Decisions it made (whether ultimately trust was successfully established or failed). If the trust evidence hash indicates no change, then related decisions can be re-used to speed re-establishing trust for the same purpose & context)

Notes on the modelling

The current model only shows one side Alice's view of sending TERs to Bob. It also needs to show Req/Response for trust questions in both directions.

There are clearly some collection of objects and workflows that need to be packaged as building blocks and shown in modelling diagrams.

A Trust Request/Decision Block (TRDB) includes

• A Decision algorithm/assistant (helper, guide, agent...) will be loaded for each block along with User provided decision parameters
• Decision blocks can be nested in that an outer block can contain 2 or more inner blocks such that there may be a decision about each of the inner blocks and an overall decision (outer block) examining the decisions and evidence of the two inner blocks
• A Trust Request Topic is a collection of logically related TERs
• A TRBD contains
  • a decision algorithm object
    • decision parameter set
  • one or more trust evidence requests
  • Trust Evidence Requests will typically be grouped into an ordered collection of requests by topic (see above)
    • which may have their own logic as to which requests to run or skip based on decisions about previous TERs

Each Trust request

• A Trust Request is parameterized request, plus a versioned Trust Document format and schema as the required response.
  • In many cases, the Trust Document and schema may be sufficient in terms of specifying any parameters.
• Trust topic - recommend that a list of Trust Topics be agreed to by both Parties (group of TERs) early in the interaction.
• A response by a Party to a TER can be one of several responses (need to name them)
  • The requested Trust Document (TDoc)
  • A proposed equivalent TDoc
  • Rejection of the question
    • Request of alternative

Decision Parameters may be a combination of system defaults, user preferences, past user decision responses, and ecosystem experience suggested values from composite interaction by many/all Parties in the ecosystem for that particular counterparty, context, purpose (or other combinations)

It is not clear if the TER list from Alice to Bob has to be the same as Bob to Alice. Nor is it clear how to interleave requests (TRDB from Alice, then from Bob). The proposed default would be alternating by Topic/TRDB.

It would be useful if Alice and Bob could exchange what the TRDBs were to see that they concur on which topics to request, which are common and which are unique to their side of the relationship. This also suggests needing to work out the ordering sequence.

There are several motivations for how to order TERs

• Trust Dependencies - e.g. in order (from first to last)
  • Ecosystem compatibility/trust evaluation - logically, this is the first question to resolve. Reasons it may come later?
  • Trust Request topics and TRDB order
  • Party Identifier
  • Party Wallet & components
  • Biometrics (if needed, position in dependency sequence could depend on purpose/context, preferences by the 2 Parties)
    • Biometrics will be self-evaluating (on the device/system of the Party vs. by other Party, 3rd Party)
  • Non-sensitive VCs
  • Sensitive VCs
  • Data Exchange
  • ... Application-specific trust
• Minimizing PII/Sensitive disclosure
• Blocking Phishing and other attacks

Particularly in each implementation for Trust Est Wflw, there may be the need for non-trivial negotiation on the order, type and specific trust requests that will be exchanged.

Requirement - completely avoid exchanging Sensitive/PII information

Use Case - women seeking access to abortion pills in areas in the US where women can potentially be reported and charged with a crime for seeking access or exposing themselves as being pregnant and subject to medical surveillance and medical restrictions.

The technical requirement to establish trust and exchange data in an anonymized manner without compromising the security and authenticity of the TEWF

Solution - Trust establishment via a trusted 3rd party - another variation on the intermediary/digital notary case. Each party establishes trust with the intermediary who acts as a broker for each party, who confirms to each Party that the other is legitimate and is authentic without revealing potentially compromising information.

Need for a Trust Agent
Verifying if both parties are permitted to request information (selective disclosure of VC claims and for exchange of general data (e.g., medical records))

Assumptions:

• For Verifiers, the ability to request sensitive data will be part of their Verifier Credentials

Desirable features:

• An Agent can flag sensitive information that is permitted but that the sharing Party may choose not to share. This might be a Party/Holder specific configuration as to what data (personal consent preferences).
• A Trust Agent could evaluate TERs, and particularly PII/Sensitive data requests, based on the requestor's stated purpose and context.

Party Roles for Interaction

In most cases, in a 2 Party interaction, one Party is the initiator. It has been discussed (Trust Spanning Layer) that the initiator should be required to specify the purpose and context for the request. This emulates being cold-called in a phone, text or email conversation. The person receiving the "call" is most likely to reject the call if the purpose and context for the call are not offered.

For a Trust Establishment Workflow, as in an interpersonal conversation, the details (and ramifications) of the purpose and context need to be established with the first request or very early in the interaction. More details will emerge through the workflow as more trust information is exchanged (although the correlation may not be 1-for-1), with full understanding not achievable until late in the workflow process and possibly not until well into application-specific interaction (e.g., discussing terms and conditions of a financial transaction or data exchange).

The TEWF certainly supports that in all messaging, that purpose (simple phrase of intent) and context (details of the purpose and the circumstances/context under which the purpose will be implemented or performed. This should sync with the Trust Spanning Layer Protocol 

Additional Post Meeting comments by Carly 

Thinking of today's discussion and this ToIP paper:
https://trustoverip.org/wp-content/uploads/ToIP-Decentralized-SSI-Governance-V2.0-2022-01-06.pdf"This would mean a set of standardized protocols exist (analogous to HTTP and FTP) for issuing credentials and
obtaining them, as well as for requesting and obtaining ‘presentations’, i.e. data constructs that contain (parts
of) different credentials (issued by various parties) and (cryptographic) proofs of provenance, immutability, etc."Could this become more general to fit in with our discussion from today - protocols for the exchange of trust objects (can't remember today's term), not just credentials or presentations?

"Users provide credentials as an equivalent of filling in forms. Few realize that this is only one-half of the negotiation of a transaction and that users, too, might want to learn more about the party to which they provide their data to. If they can, they might be able to better determine whether it is a legitimate business or a scam, whether the party is
properly accredited to handle the data (e.g. a health organization), etc. So, parties in a holder role should typically
be enabled to asynchronously/simultaneously perform in the validator role so as to balance the transaction
negotiation.14 Note that this implies that wallet apps should accommodate this (by adding capabilities to send
presentation requests and handling the responses), as should web servers (by adding capabilities that can handle
presentation requests)."https://trustoverip.org/wp-content/uploads/ToIP-Decentralized-SSI-Governance-V2.0-2022-01-06.pdfThis directly relates to our data model discussion today where we also discussed the need to have a transactional protocol for negotiation of information exchange.