[KBS] Abstraction layer for different Attestation Services Backends

[Xynnn007]

Background

Currently, we allow KBS to interact with multiple ASs by implementing the trait (not required all, but at least verify). To manage API access based on the attestation, KBS currently uses a unified resource policy.

What We are Facing?

• We assume that all different ASes are returning a JWT (namely, attestation token), including CoCoAS, ITA and Keylime(WIP). Potentially more AS types.
• The input to the resource policy is directly the claims field of the JWT.
• Different attestation token types will have different fields in the claims.
• The example KBS resource applies only for CoCoAS' EAR Token.
• So, if any developer wants to use KBS to connect to AS services other than CoCoAS, they will need to customize the KBS policy based on the concrete token format they choose to receive from the AS. In other words, currently KBS resource policy is tightly coupled with the concrete backend AS.

This issue raises this point primarily to encourage everyone to assess whether it's a problem.

As the Trustee ecosystem is further promoted, more and more Action Services (AS) will be integrated into the backend support of KBS. The goal is to ensure that the KBS itself, the plugin implementation, and the KBS policy writing remain unchanged when the backend AS is replaced, in order to achieve decoupling.

IMPO, since KBS and AS are separate components, it must provide a common abstraction for the returned tokens across different ASs.

How we can deal with it?

This means abstracting a semantic set for AS tokens in different contexts (whether it's CoCoAS's EAR or ITA's JWT), which should at least include the following:

• attestation_summary: A minimal, authorization-oriented view derived from attestation results, such as the coarse-grained trust outcomes. (we can discuss about the concrete in a separate thread if needed)
• an evidence-bound tee pubkey: This is the core value that KBS with its RCAR handshake provides - a TEE key pair that is bound to the concrete client platform.
• custom_claims: any AS-specific extensions (e.g. extensions including validated identifiers in EAR)

Let's call it Trust Context for better wording. The Trust Context should be represented ONLY INSIDE KBS. The returned thing from KBS to the Client after RCAR is still the token generated by the backend AS.

TC Usages

TC can be used in two cases

• To call the concrete plugin of KBS, TC should be added to the function. Then the concrete plugin can do different operations based on the TC. e.g., hsm can only return the key when TC meets some needs.
• KBS resource policy.

How to generate TC?

After an overall structure of TC is defined, different AS backend plugin should implement another function in the trait

fn claims_to_tc(&self, claims: serde_json::Value) -> Result<TC>;

Which maps token-specific claims into the TC.