Re: [Rats] 答复: Another RATS message flow model for consideration:

"Smith, Ned" <> Mon, 18 November 2019 16:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C1A55120111 for <>; Mon, 18 Nov 2019 08:25:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KCWxEnpfv9xJ for <>; Mon, 18 Nov 2019 08:25:35 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A43312007A for <>; Mon, 18 Nov 2019 08:25:35 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Nov 2019 08:25:34 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.68,320,1569308400"; d="scan'208,217";a="407442988"
Received: from ([]) by with ESMTP; 18 Nov 2019 08:25:34 -0800
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 18 Nov 2019 08:25:34 -0800
Received: from ([]) by ([]) with mapi id 14.03.0439.000; Mon, 18 Nov 2019 08:25:33 -0800
From: "Smith, Ned" <>
To: "Xialiang (Frank, Network Standard & Patent Dept)" <>, "" <>
Thread-Topic: =?utf-8?B?W1JhdHNdIOetlOWkjTogQW5vdGhlciBSQVRTIG1lc3NhZ2UgZmxvdyBtb2Rl?= =?utf-8?Q?l_for_consideration:?=
Thread-Index: AQHVnizNPQKKKNhUk0ik7vfZORuaAg==
Date: Mon, 18 Nov 2019 16:25:33 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.1f.0.191110
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_AE350A78D48C4183BDEC82DA4EE8A49Fintelcom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Rats] =?utf-8?b?562U5aSNOiBBbm90aGVyIFJBVFMgbWVzc2FnZSBmbG93?= =?utf-8?q?_model_for_consideration=3A?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Nov 2019 16:25:37 -0000

This “architectural model” parallels the roles message flow. I think it could be viewed as a third model something like a pub-sub broker where Relying Parties subscribe to Verifier (broker) to receive Attestation Results and Attesters publish to Verifier (broker) when a change to the Evidence is found.

A pub-sub model might treat Claims as pub-sub Topics that can be subscribed to or published to.

I get that some pub-sub architectures eliminate the broker as a distinct entity, but conceptually the model isn’t fundamentally different than if there were a central broker.


From: RATS <> on behalf of "Xialiang (Frank, Network Standard & Patent Dept)" <>
Date: Saturday, November 16, 2019 at 2:17 AM
To: "" <>
Subject: [Rats] 答复: Another RATS message flow model for consideration:

Oops, Some fixes of the below text:

发件人: RATS [] 代表 Xialiang (Frank, Network Standard & Patent Dept)
发送时间: 2019年11月16日 18:13
主题: [Rats] Another RATS message flow model for consideration:

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 not seen by the relying party, attestation results is not seen by the attester.

I am wondering whether the architecture draft will consider it?