Add a hint to the RP about which verifier to call

[ounsworth]

Idea: add an OPTIONAL FQDN to the EvidenceStatement as a hint from the Attester to the RP about which Verifier to pass the evidence to. Related to the concept of "Audience".

This came up in discussion because some people were imagining that the EvidenceStatement.type OID would serve this purpose, but other people pointed out that this will not be the case when EvidenceStatement.type is, for example, "TCG_TPM" or "CMW".

There is a security question here about whether the not-yet-verified data should be allowed to tell the RP which code to call.

[Akretsch]

Maybe a GeneralName instead of a simple FQDN would be more ASN.1 style.

[thomas-fossati]

There is a security question here about whether the not-yet-verified data should be allowed to tell the RP which code to call.

☝️

The RP must have a pre-established trust relationship with the verifier(s), surely it can't blindly follow a potentially malicious routing hint.

This came up in discussion because some people were imagining that the EvidenceStatement.type OID would serve this purpose, but other people pointed out that this will not be the case when EvidenceStatement.type is, for example, "TCG_TPM" or "CMW".

Noting that CMW is a typed object so, in that sense, it's equivalent to EvidenceStatement: instead of EvidenceStatement.type OID the RP could use CMW's media type.

[hannestschofenig]

Henk proposed to use the information related to the digital signature covering the Evidence to make a decision about where to route the Evidence to. I looked at one Evidence format, the PSA Attestation Token, and it does not carry information about the Verifier as part of the signature meta-data structure in its default form. (We only recently added the ability to carry certificate chains in the header as part of the x5chain header in a note).

Of course, this information could be included mandatorily but I don't think it is common in other Evidence formats either.

Even if we require this information to be included in every Evidence format, it means that the relying party needs to understands more about the encoding of the Evidence in order to make an assessment about where to route the Evidence.

[thomas-fossati]

I think an assumption that can be safely made is that the RP must be pre-configured with a list of trusted verifiers, each with its own network endpoints, API details, and authentication credentials.

A routing hint would then be a key that locates the verifier slot within such a list.

And that means that we'd need to agree on the "trusted verifiers configuration list" format in the first place.

[ounsworth]

@hannestschofenig , @thomas-fossati please review PR #72 to see if it addresses this thread.