Change:
1) Avoid the term "mutual attestation" 2) Add reference to CCC whitepaper for discussion of anonymous attestation Signed-off-by: Dave Thaler
Does this term (Mutual Authentication) need to be defined? Aren’t there lots of cases where mutual attestation might be employed?
We have not defined Mutual Authentication, why would Mutual Attestation be any different?
Could there be a reference to this other document, C3 document. I don’t know what it means, but all the cases here seem to ultimately rely on a unitary Verifier/Relying-Party somewhere in the chain. Maybe that’s not true… if the verifier and relying party trust each other by fiat, the roles need not be combined.
It means this: Say you have devices A (normally an Attester) and V (normally a Verifier) and RP (normally a Relying Party). A can say it won't send Evidence to V unless V first attests to A. Thus, A starts by acting as a Relying Party where V is the Attester. If A devices that V is trustworthy, then A can start sending sensitive Evidence to V. Note this does not require anywhere have a combined Verifier/Relying Party.
I can see how: "Verifier/Relying Party" looks misleading here Dave illustrated well that this text is not about a "unitary Verifier/Relying-Party" this is related to the current mutual authentication/attestation discussion that recently emerged I'll try to pitch this issues in the next meeting so we can deal with it in the same swoop as mutual authentication. Personally, I'd simply leave the text as is.
reference
closed with email: URL
Closing since Michael's comment above says "closed with email" but didn't actually close the issue EMAIL wrote: The design team closed a few remaining issues and pull requests. Two pull requests turned out to fix the same text, so we needed to be sure we really liked the text we chose. On issue , wontfix: URL -- Attester We discussed the issue of how the RP trusts that the Verifier is operating correctly. (Who Verifies the Verifier?) This does not lead to architecting a "unitary Verifier/Relying-Party somewhere in the chain", as the roles can still be split out. When we dealt with the "mutual attestation" issue, in URL we changed text that has relevance to this issue. We have no issues open. No pull requests. If the Shepherd hasn't already started, then they should please start. Michael Richardson . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide

Discussion:
first act as an Attester, providing Evidence that the Owner can appraise, before the Owner would give the Relying Party an updated policy that might contain sensitive information.  In such a case, <del> mutual authentication or attestation might be needed, in which case typically one side's Evidence must be considered safe to share with an untrusted entity, in order to bootstrap the sequence. </del> <ins> authentication or attestation in both directions might be needed, in which case typically one side's Evidence must be considered safe to share with an untrusted entity, in order to bootstrap the sequence. See privacy-considerations for more discussion. </ins> 7.4.

Verifier Owner may need to trust the Verifier before giving the Endorsement, Reference Values, or appraisal policy to it.  This can be done similarly to how a Relying Party might establish trust in a <del> Verifier as discussed above, and in such a case, mutual authentication or attestation might even be needed as discussed in rpowner-trust. </del> <ins> Verifier. As discusssed in rpowner-trust, authentication or attestation in both directions might be needed, in which case typically one side's identity or Evidence must be considered safe to share with an untrusted entity, in order to bootstrap the sequence.  See privacy- considerations for more discussion. </ins> 8.

a Relying Party would appraise an Attestation Result for any other purpose. <ins> Another approach to deal with Evidence is to remove PII from the Evidence while still being able to verify that the Attester is one of a large set.  This approach is often called "Direct Anonymous Attestation".  See CCC-DeepDive section 6.2 for more discussion. </ins> 12. 12.1.