Re: [Rats] Verifier Input instead of Endorsement?

[Laurence Lundblade <[e-mail]>]

> On Jul 4, 2020, at 4:18 PM, Michael Richardson <[e-mail]> wrote:
> 
> 
> Laurence Lundblade <[e-mail]> wrote:
>>> Laurence Lundblade <[e-mail]> wrote:
>>>> The problem with Endorser is that they produce Endorsements and I think there are problems with Endorsements:
>>> 
>>>> - In Berlin you told me they don’t have keys in them. So then how do
>>>> keys get into the Verifier?
>>> 
>>> Well, first, I thought we agreed that the arcs above Verifier were out of
>>> scope for the architecture.  The WG might recharter to include that, but I
>>> thought we agreed that the concerns were seperable.  HOWEVER...
> 
>> If that’s the approach, then Endorsements should be removed from the
>> document, both in the text and diagram.
> 
> That makes no sense to me.
> 
> It is perfectly reasonable to define something just well enough in order to make it
> clear what is out of scope for standardization.
> 
> We can come up with many different ways to standardize Endorsements (or
> Verifier Inputs), and it shouldn't matter at all to the protocol between
> Attester and Verifier.
> 
> That's what makes it seperable.
> Do you agree?

Sorry, didn’t say that right. 

If we’re going to minimize description of what is above the Verifier, then the term “Endorsement” should be replaced with a more general term like “Verifier Input” or “Attester Trust Criteria” or other.

I think there are three problems with the term “Endorsement":
- It implies a specific style of input (a signed document) that is too narrow for a general architecture
- It is ambiguous and/or not clear it is even correct. The room in Berlin of experts agreed that Endorsement can’t have keys in them, but there must be a key input to the Verifier.
- It is TCG-specific. The term is not used in FIDO, Android and TEE-based projects that I’ve worked on.


Some text like this?

Verifier Input

Inputs used by the Verifier to establish trust in Attester, evaluate Attestation Evidence and produce Attestation results. It may include cryptographic keys, known-good/reference values, static implicit claims and policy configuration.

LL