[Rats] Another RATS message flow model for consideration:

"Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com> Sat, 16 November 2019 10:13 UTC

Return-Path: <frank.xialiang@huawei.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607F3120019 for <rats@ietfa.amsl.com>; Sat, 16 Nov 2019 02:13:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYFltd_8gJ9r for <rats@ietfa.amsl.com>; Sat, 16 Nov 2019 02:13:05 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 695F9120119 for <rats@ietf.org>; Sat, 16 Nov 2019 02:13:05 -0800 (PST)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 0AB5DDBF086A55A7D5A1 for <rats@ietf.org>; Sat, 16 Nov 2019 10:13:03 +0000 (GMT)
Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 16 Nov 2019 10:13:02 +0000
Received: from DGGEMM531-MBS.china.huawei.com ([169.254.6.245]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0439.000; Sat, 16 Nov 2019 18:12:58 +0800
From: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>
To: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: Another RATS message flow model for consideration:
Thread-Index: AdWcZLOLxoSOwSr8Rf6Q6jmW1MwH1g==
Date: Sat, 16 Nov 2019 10:12:57 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F13EA3964E@DGGEMM531-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.52.32.53]
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F13EA3964EDGGEMM531MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/NFAWH4hbNbMt5C_ODfmCq7MpSzE>
Subject: [Rats] Another RATS message flow model for consideration:
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Nov 2019 10:13:07 -0000

Hi RATS architecture design team and all,
In addition to the current passport model and background check model. I think there is a third message flow model possibly for us to consider:
Attester < -------------------- > verifier < -------------------------------- > relying party
            Evidence               attestation results

The key point of the above model is that verifier has independent connection with attester and relying party respectively, and there are two independent message exchanges between the attester and verifier, between the verifier and the relying party. Of course, if needed, there can be some trigger condition and interaction between these two connections.
The relative advantage of the above model is simple, and each role only see what he needs to see, like: evidence is only seen by relying party, attestation results is seen by attester.

I am wondering whether the architecture draft will consider it?

B.R.
Frank