RefValIDs and TrustAnchorIDs in `proto` Evidence Context

[yogeshbdeshpande]

The current proto interface between Verification Front End and VTS returns an AppraisalContext which has the
EvidenceContext.

It is NOT clear as to following:

1. Why the EvidenceContext should have trust-anchor-ids &reference-ids
2. What is the need of the same to be returned to the Verification front end?
3. Even if it is needed, it is not the correct structure to hold this.

[setrofim]

1, 3: I agree that them being part of EvidenceContext is weird; it would make more sense for them to be part of AppraisalContext directly.
2: They are included in the AppraisalContext because they are part of that context -- they inform how the attestation result was generated.

I think they original idea was to make the appraisal context available to the front end so that it could, in turn, be propagated to the caller as additional information (e.g. if an appraisal returned other than "affirming", having the context would allow the caller to potentially "diagnose" the issue).

In practice, the frontend doesn't do anything with the context, apart from extracting and returning the encoded EAR. As such, I think the right question isn't whether the IDs should be included inside AppraisalContext, but whether VTS should return an AppraisalContext from GetAttestation() at all, or just a []byte containing the encoded EAR.

My 2 cents is that things probably fine as they are -- even if the fontend is not doing anything with it today, we may want the context later; and it is, at least in principle, possible that the VTS client will be used by something other than than the frontends. Returning the full context makes sense as part of a general-purpose API. The only downside I see is the additional overhead of conveying the context across the GRPC interface, and that is negligible in the context (pun? intended) of the overall cost of the evidence appraisal call.