Re: [Rats] Question about WG Procedure -- Re: 答复: Use case -> architecture document

["Smith, Ned" <[e-mail]>]

Speaking as a co-chair the activity on the list related to architecture at the very least points to consensus around a desire/need for an architecture draft to be adopted. The original milestones suggested that the timing could lag that of other drafts (that seem to address more immediate needs.) Maybe that is no longer the case because of a need to agree on terminology, attestation workflows or connection endpoint semantics? List activity seems to suggest the latter – at least in terms of adopting an architecture draft that is recognized as a starting point for the architecture. There may be differences of opinion on what content should exist in the starting point.

Speaking as one of the authors of the birkholtz arch draft (h.arch) the primary contribution it makes (as a starting point) is the definition of a set of roles and messages that make up an attestation system.

The thaler arch draft (t.arch) seems to focus primarily on protocol endpoint interactions and coins the terms “passport” and “background check” as a way to model connectivity paths. The endpoint names in t.arch appear to overlap/conflate role names in b.arch. This may be confusing or illustrative depending on the reader.

The h.arch roles architecture purposefully avoids trying to capture endpoint connectivity semantics so that the role interactions could be appreciated. A litmus test for roles might be that addition of endpoint connectivity semantics shouldn’t breaks roles definitions. The t.arch defines two connectivity models (passport and background check) that are very relevant to TEEP but may also be relevant outside of a TEEP context. There are other connectivity models not described by either h.arch or t.arch for example broadcast/multicast, pub-sub, mesh, blockchain. An expectation of the h.arch is that a mapping of roles onto a broad spectrum of connectivity models will preserve the defined role-message interactions. The connectivity arch models in t.arch seems to demonstrate the validity of the h.arch roles model since the mapping in t.arch borrows the terminology and semantics of h.arch.

The h.arch doesn’t have a section that details various endpoint connectivity options. Such a section could go in a couple of directions (1) identify the need for mapping roles to connectivity endpoints and connectivity semantics, (e.g. request-response, pub-sub, mesh, blockchain); but stop short of defining them in the arch draft or (2) define the possible connectivity models with role mappings, but inclusion in the RATS arch draft would be exemplary.

Given passport and background check models (and variations / hybrids) seem to be highly synergistic with TEEP. If option (1) is desirable, the TEEP arch draft could be a good place to map the passport and background check models to RATS roles. If option (2) is desirable, the TEEP arch might still need to qualify what the RATS arch considers as exemplary.

-Ned

On 10/15/19, 15:56 PM, "RATS on behalf of Thomas Hardjono" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:


​

My apologies that this email is late.  I'm just catching up on the reading RATS mail-list.



In her 10/8th email Kathleen has suggested some major changes to the direction of the RATS architecture as a whole, which may have dramatic impact on the applicability of RATS to broader scenarios.



So I have a question about WG procedure: what is the role/capacity and weight of a co-chair when the person makes statements.



I'd also like to hear from the other two co-chairs on this matter.





Apologies again for the delay.





-- thomas --



​

________________________________
From: RATS <[e-mail]> on behalf of Xialiang (Frank, Network Standard & Patent Dept) <[e-mail]>
Sent: Wednesday, October 9, 2019 6:53 AM
To: Kathleen Moriarty
Cc: [e-mail]
Subject: [Rats] 答复: Use case -> architecture document


Hi Kathleen,



I am very concerned with this new direction and I strongly object.



Current architecture draft goes through a lot discussions and reaches many consensus. Right now, it really helps IETF (Teep for example), FIDO, TCG and many others. The only issues are on readability, the standards track and the completeness (e.g., passport and background check are still missing). It is an very good document and correct terminology is very important for remote attestation.



About use cases document, Its goal is just to clarify a sample list of scenarios that remote attestation can apply to and then deduce the requirements and the following concrete protocol drafts. It is not fit to be an architecture.



The current architecture is too important for telecom and network equipment vendors and service providers. I have strong doubts that current EAT and OTrPv2 alone is suitable for the (virtualized) network infrastructure situation.



B.R.

Frank
[cid:[e-mail]7B1510]

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

发件人: RATS [mailto:[e-mail]] 代表 Kathleen Moriarty
发送时间: 2019年10月8日 19:25
收件人: [e-mail]
主题: [Rats] Use case -> architecture document

Hello!

I read through the latest version of the ‘use case’ document yesterday and found it very easy to read and understand, meaning I think it is written well and could be easily understood by many without having to climb up a learning curve.

First, this could be a very useful document to register claims for the use cases.

Second, if the workflow for the passport and background check were added and put in terms of the open trust protocol v2 from TEEP, we have a fairly nice architecture document that’s easy to read and may gain adoption.  The workflows cover the various interactions between roles and TEEP has actively broken up OTrP in v2 to accommodate using EAT tokens, this would help create that link and make it very clear.

The other thing I like about the use case document and think we should expand on is the references to other work items.  This makes it an architecture document that maps out the full plan of the WG.  One like that was extremely well received by all the ADs that don’t like informational/helpful documents.

I’m a bit nervous with the terminology being defined and would love to see something like this that’s simplified and more easily adoptable.

I appreciate the work done to improve the architecture document, but I do think the structure changes to the use case document as suggested could result in an easier to understand (and therefore easier to adopt) document.

While the architecture document is more readable, I think we can do better.  Adoption is important and our timeliness matters a lot for this work.  EATs can be used for may use cases with OTrPv2, so let's keep it as simple as we can.

Thoughts are appreciated.

Best regards,
Kathleen--

Best regards,
Kathleen