Criteria for our VID Appraisability Framework

[talltree]

In our 2023-09-27 TSPTF meeting, we discussed the following proposed text for section 2.1.5 of the specification:

When an endpoint is about to send to or receive from a VID, it must assess the trust basis of this VID. Note that this procedure concerns the assessment of the identifier itself, not the controller nor the subject of the identifier. Part of this assessment is done through the verification procedure (section 2.1.2), but for some applications that may not be sufficient.

The term we have proposed for this assessment process is appraisability. Here is the current definition of that term in the ToIP Glossary:

appraisability (of a communications endpoint)

The ability for a communication endpoint identified with a verifiable identifier to be appraised for the set of its properties that enable a relying party or a verifier to make a trust decision about communicating with that endpoint.

See also: trust basis, verifiability.

The purpose of this discussion is to propose specific criteria that should be included in our appraisability framework. Please make each proposal a separate thread, and include in the starting post for the thread:

1. Short name for the criteria.
2. Description of the criteria and how it would be represented technically (e.g., property names and values).
3. Explanation of why the criteria should be part of the appraisability framework and how a verifier is likely to use it to help determine their trust basis.

[SmithSamuelM]

Appraise the Trust Basis then the key management properties given that trust basis. Trust basis includes the primary and secondary roots-of-trust. Are these autonomic (cryptographic zero-trust), administrative, or algorithmic)

Key management: single sig, type of signature algorithm ECDSA, ED25519 etc, Multi-sig, type of multi-sig threshold. etc

Key creation mechanism (HDK or random salt)
Key storage mechanism (HSM or other storage) Multi-factor protection
Key signing mechanism (HSM, Enclave, in memory etc)

Key state change (rotation) mechanism (verifiable, asserted, or multiply asserted etc)
Key state verification mechanism
Protections on key state publication and verification

[talltree]

@SmithSamuelM, that's a pretty good list. If I understand your proposal, does the top level choice (administrative, algorithmic, or autonomic) then tree out into a different set of supporting properties for each of those three choices?

For example, the trust basis for an administrative VID (e.g., one based on an X.509 cert, for example) would seem to involve the CA's security practices, where as an algorithmic VID (e.g., one based on a blockchain) would involved the blockchain's security practices. Your post describes the supporting properties for an autonomic VID (e.g., a KERI AID).

Would you agree?

[SmithSamuelM]

@talltree yes

[IDmachines]

Perhaps our (ANCR WG at Kantara) Transparency Performance Scheme and Indicators, could be used as a part of a framework for controller assessment, along with the receipt it can generate. https://github.com/KantaraInitiative/WG-ANCR/blob/main/TPI/ANCR-Digital-Transaprency-Scheme-v0.9.1.pdf From: Drummond Reed ***@***.***> Sent: Tuesday, October 3, 2023 10:42 PM To: trustoverip/trust-spanning-protocol ***@***.***> Cc: Subscribed ***@***.***> Subject: [trustoverip/trust-spanning-protocol] Criteria for our VID Appraisability Framework (Discussion #47) In our 2023-09-27 TSPTF meeting, we discussed the following proposed text for section 2.1.5 of the specification: When an endpoint is about to send to or receive from a VID, it must assess the trust basis of this VID. Note that this procedure concerns the assessment of the identifier itself, not the controller nor the subject of the identifier. Part of this assessment is done through the verification procedure (section 2.1.2), but for some applications that may not be sufficient. The purpose of this discussion is to propose specific criteria that should be included in our appraisability framework. Please make each proposal a separate thread, and include in the starting post for the thread: 1. Short name for the criteria. 2. Description of the criteria and how it would be represented technically (e.g., property names and values). 3. Explanation of why the criteria should be part of the appraisability framework and how a verifier is likely to use it to help determine their trust basis. — Reply to this email directly, view it on GitHub <#47> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHY7P3AVP23W4BW25MFAL3X5TEHFAVCNFSM6AAAAAA5R4MPCCVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZVGY4TSMBVG4> . You are receiving this because you are subscribed to this thread. <https://github.com/notifications/beacon/AAHY7P2OOLHWAKPKRBW7TCDX5TEHFA5CNFSM6AAAAAA5R4MPCCWGG33NNVSW45C7OR4XAZNKIRUXGY3VONZWS33OVJRW63LNMVXHIX3JMTHAAVXV6E.gif> Message ID: ***@***.*** ***@***.***> >

[talltree]

@IDmachines, thanks for the suggestion. I looked over your spec and it appears to mostly address transparency with regard to the handling of PII. The goal of our VID appraisability framework is for the VID controller to assert the trust basis for the VID. This is primarily its technical characteristics (as Sam Smith's post points out, the architecture of the VID itself and its underlying key management). So it seems like our VID Appraisability Framework might be a potential component of your Transparency Performance Scheme and Indicators spec. Does that make sense?

[IDmachines]

Just saw this @talltree it is relevant for any controller, yes it will leverage anything available about the controller, which is the top of the food chain, and then any other delegates. Not so much about PII (though you need to cover this in the notice), as it is who is in control and how transparent, proportional an reciprocal the controller and relationship is operationallly.

We would measure the transparency performance of the VID Controller, in response to your latest comment, there is no need for a request, this should all be available for evaluation without a request, i.e. transparent and then you can measure if this is true (TPI 1 timing of notice (appraisal, notice is really making transparency the risk, so behind the appraisal there needs to be some kind of already performed risk assessment, TPI 2 is content, so if the appraisal worth the time of data, TPI 3 what can I do with the information, e.g. how can I follow up with the information, and TPI 4 is whether security is contextual, and from what jurisdictional (governance) perspective.

[darrellodonnell]

I think there is some value in considering the following:

• Distribution - where is the key material to be found for referenceability.
• Discovery - where can the identifier be found (e.g. what trust registries).
• Primacy - where is the primary "source of truth" for an identifier (and its data+metadata).

[TelegramSam]

Is this only appraising trust? Or other important aspects, such as endpoint support for needed protocols?

[SmithSamuelM]

@TelegramSam I believe endpoint support is part of the VID supporting services for each type of VID. The appraisal framework is to enable a potential interactor or business logic to decide if they want to trust a given VID type or a given configuration of a given VID type. I think that how the VID goes about using endpoints could be part of the trust appraisal but not the actual protocol and infrastructuyre that does the endpoint support. Like are endpoints considered verifiable trusted or are they merely untrusted discovery services for other verifiable services. A zero-trust breakdown of what is trusted, trustable, verifiable (not trusted unless verified) etc is what an appraisal framework is all about. For a good example of work along these lines look at the IETF RATS attestestation specs which come from the trusted computing group. The term “appraisal” is inspired by their use of the term.

[talltree]

@SmithSamuelM Do you have a specific link for the IETF RATS attestation framework?

[SmithSamuelM]

RATS

[SmithSamuelM]

RATS

RATS

Remote attestation procedures (RATS) determine whether relying parties can establish a level of confidence in the trustworthiness of remote peers, called Attesters. The objective is achieved by a two-stage appraisal procedure facilitated by a trusted third party, called Verifier, with trusted links to the supply chain.

The procedures for the two stages are:

Evidence Appraisal: a Verifier applies policy and supply chain input, such as Endorsements and References Values, to create Attestation Results from Evidence.

Attestation Results Appraisal: a Relying Party applies policy to Attestation Results associated with an Attester's Evidence that originates from a trusted Verifier. The results are trust decisions regarding the Attester.

To improve the confidence in a system component's trustworthiness, a relying party may require evidence about:

system component identity,
composition of system components, including nested components,
roots of trust,
an assertion/claim origination or provenance,
manufacturing origin,
system component integrity,
system component configuration,
operational state and measurements of steps which led to the operational state, or

other factors that could influence trust decisions.

ToIP

The difference is that the RATS appraisal framework is largely driven by the needs of apprising the hardware and firmware of trusted computing devices and requires a trusted third party. The ToIP appraisal framework is meant for end-to-end-verifiable appraisal without a trusted third party. It is mean to enable a verifier (end) to appraise the trustworthiness of someone else’s VID. This end-verifiability means that the VID being appraised must produce verifiable evidence of trustworthiness. It operates at a higher level than RATS. The ToIP appraisal assumes that the root-of-trust is either autonomic, algorithmic, or administrative. This could be augmented by a RATS appraisal of the hardware/firmware of an underlying HSM, secure enclave, or TEE. But that augmentation is out of scope for the ToIP appraisal framework.

[SmithSamuelM]

For example, a KERI AID is a type of VID that is designed to be appraisable in a cryptographically verifiable way. We call this verifiability-by-design (VbD). The essential basis we call duplicity evident computing: All KERI verifiable data structures are designed to make them duplicity evident. This is similar to tamper-evident computing where every variable has a hash. A duplicity evident data structure is immutable append only hash chained and non-repudiably signed. A different version of such a data structure that is not identical for all common elements is provable evidence of duplicity. A verifier asks the question: Is there any evidence of duplicity? If not then trust. If so then do not trust until such duplicity has been reconciled (if at all). It is up to the verifier to manage its duplicity detection infrastructure so that it can ask and answer its own question, that is, is there evidence of duplicity?

All AID controllers are accountable for key compromise of their own keys. A Witness pool provides a Threshold of Accountable Duplicity (ToAD). Above the threshold any events in the associated KEL replicas provided by the Witnesses are accountable to the controller and may be trusted by the verifier (assuming the verifier accepts the threshold). A verifier could choose a higher threshold than that chosen by the controller and would therefore wait until more witnesses confirm in their replicas. Below the threshold, events in Witness pool KEL replicas are not to be trusted. So the Witness pool ToAD provides evidence of appraisability of an AID that is dynamic on an event by event basis.

Likewise the key state is appraisable based on single-sig or multi-sig and if multi-sig by the threshold of the multi-sig.

The design is meant to make as much of the infrastructure supporting an AID verifiable via cryptographic means by any verifier. Its not a separate API but baked into the protocol. For other types of VIDs that do not benefit from verifiability-by-design they must provide whatever evidence they can to a verifier for appraisal. The evidence might be all just trust me with no way to verify. In that case a given verifier might say no good enough the appraised VID would therefore not be sufficiently trustworthy.

[Oskar-van-Deventer]

The purpose of this discussion is to propose specific criteria that should be included in our appraisability framework.

@talltree Drummond, would you be so kind to include your definition of the term "appraisability" in your original post. The dictionary explanation of the word is too generic to be useful here. What are your criteria to distinguish something (a VID?) that is appraisable, and that is not?

Oskar

[talltree]

@Oskar-van-Deventer, my apologies for a delayed response. I did as you requested and added the definition of appraisability to my original post. I think it makes the criteria clear: a VID is appraisable if it supports a appraisability framework that enables a verifier to request and appraise the VID's trust properties in order to make a trust decision about interacting with it.

[Oskar-van-Deventer]

@talltree Drummond, thank you for the response, which very much helps my understanding.

Do I understand correctly that "appraisability" is subjective?

Rephrased: "a VID is appraisable to a verifier, when a sufficient amount of information is available for that verifier to make a positive trust decision about interacting with it. Some or all of such information may be made publicly available through a formal appraisability framework that provide VID's trust properties."

[IDmachines]

Why not MUST?