Recently, a discussion with @fitzthum in Confidential Containers community about how EAR Token can better support TEE identity tokenization, and more broadly, how it can better support a wider range of user-defined extensions.
Current Trust Tiers in EAR can provide a rich representation of the trustworthiness of TEE TCBs. However, in our scenario, the remote attestation policy for generating EAR tokens requires the EAR to carry some custom strings and architecture-independent fields to convey information beyond the Trust Tier. Usually these fields will help to define the software identity of the TEE.
Specifically, we will include runtime data (data that is bound to hardware evidence at runtime), initdata (data that is bound to evidence during TEE initialization), and user-data (other user-defined data that we want to include in the EAR).
All of the above data will be included in the EAR token as (nested) objects.
@thomas-fossati gave a suggestion, we can define this data to a default field in EAR standard, as a "object/map to the claims set and explain how users (e.g., CoCo) can extend it, adding new identifier types.".
Supporting this field at the standardization level will help any EAR token issuer to embed their own interpretable fields into the token as needed, and also help us handle identity issues of confidential computing.
I raise this issue to track this thread, to see if it is adoptable and practical, also more discussion.
Recently, a discussion with @fitzthum in Confidential Containers community about how EAR Token can better support TEE identity tokenization, and more broadly, how it can better support a wider range of user-defined extensions.
Current Trust Tiers in EAR can provide a rich representation of the trustworthiness of TEE TCBs. However, in our scenario, the remote attestation policy for generating EAR tokens requires the EAR to carry some custom strings and architecture-independent fields to convey information beyond the Trust Tier. Usually these fields will help to define the software identity of the TEE.
Specifically, we will include runtime data (data that is bound to hardware evidence at runtime), initdata (data that is bound to evidence during TEE initialization), and user-data (other user-defined data that we want to include in the EAR).
All of the above data will be included in the EAR token as (nested) objects.
@thomas-fossati gave a suggestion, we can define this data to a default field in EAR standard, as a "object/map to the claims set and explain how users (e.g., CoCo) can extend it, adding new identifier types.".
Supporting this field at the standardization level will help any EAR token issuer to embed their own interpretable fields into the token as needed, and also help us handle identity issues of confidential computing.
I raise this issue to track this thread, to see if it is adoptable and practical, also more discussion.