Draft: draft-ietf-rats-architecture

Commentary: 1 ) Avoid the term " mutual attestation " 2 ) Add reference to CCC whitepaper for discussion of anonymous attestation Signed - off - by :   
 Does this term ( Mutual Authentication ) need to be defined ? Are n’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 do n’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  ( normally a Verifier ) and RP ( normally a Relying Party ) . A can say it wo n'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  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 : 
 Closing since  's comment above says " closed with email " but did n't actually close the issue
Mailing list commentary: internet- 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 # 208 , wontfix : 7.2 -- 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 we changed text that has relevance to this issue . We have no issues open . No pull requests . If the has n't already started , then they should please start .
Paragraph (version A):
The Relying Party Owner might also require that the Relying Party
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,
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.
Paragraph (version B):
The Relying Party Owner might also require that the Relying Party
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,
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.
Paragraph (version A):
In some scenarios, the Endorser, Reference Value Provider, and
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
Verifier as discussed above, and in such a case, mutual
authentication or attestation might even be needed as discussed in
rpowner-trust.
Paragraph (version B):
In some scenarios, the Endorser, Reference Value Provider, and
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
Verifier.
Paragraph (version B):
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.
Paragraph (version B):
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.