[Rats] Use case -> architecture document

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Tue, 08 October 2019 11:25 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DA2B312002E for <rats@ietfa.amsl.com>; Tue, 8 Oct 2019 04:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 4mkudikjksMR for <rats@ietfa.amsl.com>; Tue, 8 Oct 2019 04:25:27 -0700 (PDT)
Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F5641200FB for <rats@ietf.org>; Tue, 8 Oct 2019 04:25:27 -0700 (PDT)
Received: by mail-ot1-x32b.google.com with SMTP id m19so13737327otp.1 for <rats@ietf.org>; Tue, 08 Oct 2019 04:25:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=RoBOtnlPtMXEzRVkmzMEnit2K0XeSyJaRHVX6jWUKQQ=; b=EGxVntoGSF9TbR2r/cA7LbOSzonFj7F3GcmDNwieQ+la+df5iXmLJbW0V/W9h6SPf1 Cm0e5gqgKnhWJ+CfGOPlDa63BteoZGPg29ENwxR5drvKMtsMWBB0meskCzV3wj8wCiYZ ORqcUl0GxMBASNXpaEVbbC2MTqoiky4JJ1mdgvHX2Y8Tx0fztSV/Tyx+Z5p1PDAN5y/C iqM+FhiXssbryOpiaQVNcdW+Fcr/JS/lkEHY1i7qU9tPRL6/X3jd49ZAcLEEgnypkqMM 7C7obzUB+1FvZxUHMmrAVBmUE4j/Dv4gKEMIDCvo90lnvoXXyA1kAGtd0xOHMZWZuGR2 9Oqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RoBOtnlPtMXEzRVkmzMEnit2K0XeSyJaRHVX6jWUKQQ=; b=adqmULXwBWMzlLoH9peVEPSc0yb7FZV8PE6ITipzlr5YAqr9uD2oHJJccZGVsqPNEQ ZLMNeQEcXq1pAD7Ne95/77wovdWHHohO5d5kWSfj8/sZqTmE6UjgiTWYma/R+TRBEC11 wtFq2P/jNq+X1PkTFYe+KXYUvchbl79tjI+Bb80k8//YSYyifWmRKywk7uEV+auRrz9y Z3hF2fe+U80QD0VwA0MUO83uli8ctUfYEO2DCUQXzwxHoylgbp5XxUuGWpjUq7+Po7ty +mcpjK1CIU8LA/bdPs/bTPGPzKxQgjRcG2YRHmT0bAT7N60hH522UPI9lEfNUkgRw8SV 1NaQ==
X-Gm-Message-State: APjAAAWjOXpAuxYG9sOXUGCwIdnShuUiVulX6ba/3Qvi+9l0UjyA7Qwt eHr/AYlB6AHAmByOHDoJqnjHs8bOfTpIxOfLvtj1vTGK1qY=
X-Google-Smtp-Source: APXvYqxazGx8/lLQbJfSwvDDLh2E+pMoqJnWZBuVitufEo2YafvWBZUPBNjRBFaOWtsURgxGNTnWuMAgnxdfoM4EM9U=
X-Received: by 2002:a9d:4e1e:: with SMTP id p30mr15187701otf.224.1570533926036; Tue, 08 Oct 2019 04:25:26 -0700 (PDT)
MIME-Version: 1.0
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Tue, 8 Oct 2019 07:24:50 -0400
Message-ID: <CAHbuEH7f0jjquR=iZDgof4DkgpZKgxEP86NcQ0A1NQ=SP+_FHA@mail.gmail.com>
To: rats@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c4eab20594646cf7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/GWzb4nA1n0GXDNCYsw19qr5IA54>
Subject: [Rats] Use case -> architecture document
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: Tue, 08 Oct 2019 11:25:29 -0000


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

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,

Best regards,