Re: [SCITT] [EXT]Re: Endor: A SCITT PoC for W3C Verifiable Credentials

Dick Brooks <dick@reliableenergyanalytics.com> Wed, 10 August 2022 19:44 UTC

Return-Path: <dick@reliableenergyanalytics.com>
X-Original-To: scitt@ietfa.amsl.com
Delivered-To: scitt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5FCC14CF1D for <scitt@ietfa.amsl.com>; Wed, 10 Aug 2022 12:44:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.804
X-Spam-Level:
X-Spam-Status: No, score=-6.804 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, RCVD_IN_DNSWL_HI=-5, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmp9GPIdo36T for <scitt@ietfa.amsl.com>; Wed, 10 Aug 2022 12:43:55 -0700 (PDT)
Received: from wforward5-smtp.messagingengine.com (wforward5-smtp.messagingengine.com [64.147.123.35]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80106C14CF17 for <scitt@ietf.org>; Wed, 10 Aug 2022 12:43:43 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailforward.west.internal (Postfix) with ESMTP id 5B1D31AC029C; Wed, 10 Aug 2022 15:43:42 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 10 Aug 2022 15:43:42 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1660160621; x=1660247021; bh=Oq643QtDXwJbJ NU6g9Oi6Yo8dNWFrVqg9LH6rFVwqD8=; b=3qruFbpwmYdJXpKnfkRzqB2A/yXZU ulPkcsoNNycAsRxfHzcY3OvarYBelGCCxbE6KyHNj5Ig2fpknBj4pO9XE+XyWgEW 0wFIzaoLOSvdOxz5yg/9Egy5jUBhGC0ek+V2IeFXnkZnvBTyMEeWd8j1JoMJiYFQ fLZOdC0IsFeDDzwN1l2li74SHld+pSYK9HTnNHmS3LBuZQ+ZHrY3PoKREhJidJzJ t0eKI+UUGddTCyrBrT1aGceaikC3PTZI4oVrow8sXD2IYu5W3BIdI1AOUcFRjY+I ncjML/1M7h2F7VRbg1LIikBbHXFUDyjUxyX1hkIPXJB6V9lBpXAH/w4hw==
X-ME-Sender: <xms:bQr0YpYtcgLvI320VXBoL3_FwJOvx4EuA105Y2LMLyLkho6LgJ9ZRg> <xme:bQr0YgZJ0AHce7nwYgBYrsqAdMJjecjshIImsKtsxLqoALiDSiP7UZa7B1X4_qIGA q9O4g0ra2I9pjQjIw>
X-ME-Received: <xmr:bQr0Yr_TMmQtIZbMYCjCLs9fFhA5Hi8wSVqI-FS1x--pXo40WVYCpxc>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdegvddgudeflecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpehrhffvvehfjgfuffhokfggtgfothesrhdtghepvddtvdenucfhrhhomhep fdffihgtkhcuuehrohhokhhsfdcuoeguihgtkhesrhgvlhhirggslhgvvghnvghrghihrg hnrghlhihtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepvdfflefhhfejlefhffeh kefggedvuddtleffudehjeduueejuddvveetueeghfegnecuffhomhgrihhnpehrvghlih grsghlvggvnhgvrhhghigrnhgrlhihthhitghsrdgtohhmpdhirghtrgdrohhrghdpohhu thhlohhokhdrtghomhdpvhgtihdrohhrghdprghpphhlvgdrtghomhdpnhgrvghssgdroh hrghdptghishgtohdrtghomhdpohgrthhirdgtohhmpdifihhkihhpvgguihgrrdhorhhg pdhgihhthhhusgdrtghomhdpfiefrdhorhhgpdhivghtfhdrohhrghdpfiefihgurdhorh hgpdgvsghirdgrtgdruhhkpdhquhguthdrohhrghdpthhrrghnshhmuhhtvgdrihhnughu shhtrhhivghsnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepughitghksehrvghlihgrsghlvggvnhgvrhhghigrnhgrlhihthhitghsrdgtohhm
X-ME-Proxy: <xmx:bQr0Ynou2W7bqN7lSaVlQPkDThgsOZTP8ElKo2IHoV8wQ0Frpi98mg> <xmx:bQr0Ykoq9jKuvjU_5Y67y1ed13fFPl6f4NY_qaFN8Q09UqgiLpKmkw> <xmx:bQr0YtQZ7YVgwAg6IPigpuBMm2WdMhddHHUxpVJAY-O4YLGEvZFI8w> <xmx:bQr0Yr12fEWZ-j7hmx5m9f7xt-4uQj9PgpXf4wCU5PiwNBL6-nD8tC6ey1s>
Feedback-ID: i57d944d0:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 10 Aug 2022 15:43:41 -0400 (EDT)
Reply-To: dick@reliableenergyanalytics.com
From: Dick Brooks <dick@reliableenergyanalytics.com>
To: 'Steve Lasker' <Steve.Lasker@microsoft.com>, "'Hart, Charlie'" <charlie.hart@hal.hitachi.com>, 'Orie Steele' <orie@transmute.industries>
Cc: 'Steve Lasker' <Steve.Lasker=40microsoft.com@dmarc.ietf.org>, scitt@ietf.org
References: <CAN8C-_K-w5QQqrZDS9VH2-gzOO9e+HS8b9nGvG+ZBjJ-PM-MCw@mail.gmail.com> <LV2PR21MB3350154C13FA8A6F9D940FA79C9C9@LV2PR21MB3350.namprd21.prod.outlook.com> <13e501d8a738$1b277ed0$51767c70$@reliableenergyanalytics.com> <CAN8C-_JvDwS4CTBJMm9YN8jdXnLATPg0j3xO5BFs+yraWZc2Yg@mail.gmail.com> <144801d8a73c$adb8dec0$092a9c40$@reliableenergyanalytics.com> <OS3PR01MB75270FA0BFF65C76B2AD2D58D19C9@OS3PR01MB7527.jpnprd01.prod.outlook.com> <OS3PR01MB75272702BC43C5DA50A57081D19C9@OS3PR01MB7527.jpnprd01.prod.outlook.com> <170b01d8a766$6cf8b110$46ea1330$@reliableenergyanalytics.com> <DS7PR21MB33410F208AF17F985E9D7F609C659@DS7PR21MB3341.namprd21.prod.outlook.com> <607401d8acec$42946370$c7bd2a50$@reliableenergyanalytics.com> <DS7PR21MB33412D4FE3057A382A2B7A939C659@DS7PR21MB3341.namprd21.prod.outlook.com>
In-Reply-To: <DS7PR21MB33412D4FE3057A382A2B7A939C659@DS7PR21MB3341.namprd21.prod.outlook.com>
Date: Wed, 10 Aug 2022 15:43:41 -0400
Organization: Reliable Energy Analytics LLC
Message-ID: <614001d8acf1$7ffc0bf0$7ff423d0$@reliableenergyanalytics.com>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_6141_01D8ACCF.F8ED0400"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFW99ZsMx84Va7zOFRPyoGd1SQCTgH1aWAUAs6kgHECt6pWGgJWRmN8Ao3zJs4B8+jajgIFfpsCAsvSdLwB4MLn+wGzs8TgrfYku2A=
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/scitt/O1BKf4yWYe-CeQm4p2xgKpDhOT0>
Subject: Re: [SCITT] [EXT]Re: Endor: A SCITT PoC for W3C Verifiable Credentials
X-BeenThere: scitt@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Supply Chain Integrity, Transparency, and Trust" <scitt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scitt>, <mailto:scitt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scitt/>
List-Post: <mailto:scitt@ietf.org>
List-Help: <mailto:scitt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scitt>, <mailto:scitt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Aug 2022 19:44:00 -0000

Thanks, Steve.

 

I had a good talk with a potential notary company yesterday about a new
service offering to software vendors conducting risk assessments and
submitting notarized evidence data to a registry, which can be queried by
anyone to check the trustworthiness of an app. Hoping to see that Company at
the SCITT table. 

 

I missed the call this week to take some time at the lake. Back home now and
ready dig deeper into use cases and templates.

 

CISA's ICT_SCRM Task Force is working on some use cases that may also be
worth considering for SCITT. Should know more about the possibilities of
this in a month or so. 

 

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council - A Public-Private Partnership

 

 <https://reliableenergyanalytics.com/products> Never trust software, always
verify and report! T

 <http://www.reliableenergyanalytics.com/>
http://www.reliableenergyanalytics.com

Email:  <mailto:dick@reliableenergyanalytics.com>
dick@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

From: Steve Lasker <Steve.Lasker@microsoft.com> 
Sent: Wednesday, August 10, 2022 3:30 PM
To: dick@reliableenergyanalytics.com; 'Hart, Charlie'
<charlie.hart@hal.hitachi.com>; Orie Steele <orie@transmute.industries>
Cc: 'Steve Lasker' <Steve.Lasker=40microsoft.com@dmarc.ietf.org>;
scitt@ietf.org
Subject: RE: [SCITT] [EXT]Re: Endor: A SCITT PoC for W3C Verifiable
Credentials

 

Merging threads from Orie

 

Dick, I completely agree. This is what I've been sharing with Kathleen as
well. Imagine each instance can configure their policy. They can have their
own unique policy for their company, they can configure a deferment to
another entity they trust for their industry (horizontal/vertical), or any
means they want. 

 

We've implemented a similar pattern with Notary v2, it just happens to be on
the client. In this case, we shift the policy to the eNotary within the
SCITT instance. 

 

From: Orie Steele orie@transmute.industries
<mailto:orie@transmute.industries>  
Sent: Wednesday, August 10, 2022 11:31 AM
To: Steve Lasker Steve.Lasker@microsoft.com
<mailto:Steve.Lasker@microsoft.com> 
Cc: dick@reliableenergyanalytics.com
<mailto:dick@reliableenergyanalytics.com> ; Hart, Charlie
charlie.hart@hal.hitachi.com <mailto:charlie.hart@hal.hitachi.com> ; Steve
Lasker Steve.Lasker=40microsoft.com@dmarc.ietf.org
<mailto:Steve.Lasker=40microsoft.com@dmarc.ietf.org> ; scitt@ietf.org
<mailto:scitt@ietf.org> 
Subject: Re: [SCITT] [EXT]Re: Endor: A SCITT PoC for W3C Verifiable
Credentials

 

> This just points to the value of having personal, company, industry policy
based trust stores

+1 to this, here are a few examples of how groups have formed their own
trust systems:

- https://www.iata.org/en/pressroom/pr/2020-12-16-01/
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iata.
org%2Fen%2Fpressroom%2Fpr%2F2020-12-16-01%2F&data=05%7C01%7CSteve.Lasker%40m
icrosoft.com%7C7abb715cafff4950746008da7afe7ebf%7C72f988bf86f141af91ab2d7cd0
11db47%7C1%7C0%7C637957530868630952%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cY9
Cu%2B9M%2FGZ%2Br0v2tbHTGmRDUvh3zfTXSpaFdC5bxFQ%3D&reserved=0>  (aviation /
travel)
- https://vci.org/issuers
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvci.org%2
Fissuers&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C7abb715cafff495074600
8da7afe7ebf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637957530868630952%
7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
LCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XIV4ul4dxni27vXrK1cgm3bLaYRPVXm%2BVwB9J
WigftQ%3D&reserved=0>  (healthcare)
-
https://support.apple.com/guide/keychain-access/what-is-keychain-access-kyca
1083/mac
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.a
pple.com%2Fguide%2Fkeychain-access%2Fwhat-is-keychain-access-kyca1083%2Fmac&
data=05%7C01%7CSteve.Lasker%40microsoft.com%7C7abb715cafff4950746008da7afe7e
bf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637957530868630952%7CUnknown
%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
n0%3D%7C3000%7C%7C%7C&sdata=m7l44jaHTfJxbzwyjoYgwKJuGNGEgpZCB3lTR1HHncc%3D&r
eserved=0>  (personal)

You can imagine scenarios where a more limited set of issuers  might be
required, or cases where you really want to be very open.

Regards,

OS

 

 

From: Dick Brooks <dick@reliableenergyanalytics.com
<mailto:dick@reliableenergyanalytics.com> > 
Sent: Wednesday, August 10, 2022 12:06 PM
To: Steve Lasker <Steve.Lasker@microsoft.com
<mailto:Steve.Lasker@microsoft.com> >; 'Hart, Charlie'
<charlie.hart@hal.hitachi.com <mailto:charlie.hart@hal.hitachi.com> >; Orie
Steele <orie@transmute.industries <mailto:orie@transmute.industries> >
Cc: 'Steve Lasker' <Steve.Lasker=40microsoft.com@dmarc.ietf.org
<mailto:Steve.Lasker=40microsoft.com@dmarc.ietf.org> >; scitt@ietf.org
<mailto:scitt@ietf.org> 
Subject: RE: [SCITT] [EXT]Re: Endor: A SCITT PoC for W3C Verifiable
Credentials

 

Steve, et al,

 

Some industries have a specific set of CA's they have vetted and approved
for use, i.e.,  energy industry transactions. 

 

I don't think a single root of trust can be implemented, practically across
all industries, if my energy industry experience is any indicator.

 

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council - A Public-Private Partnership

 

 
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Freliablee
nergyanalytics.com%2Fproducts&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C
4f2be070beef426a340e08da7b0365a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
7C637957552529574280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=p%2BCeSucz3q3DY7Q2
C1EBIuZNIKsr38O7xLh7Q6278k4%3D&reserved=0> Never trust software, always
verify and report! T

 
<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.reliab
leenergyanalytics.com%2F&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C4f2be
070beef426a340e08da7b0365a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637
957552529574280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BPFQpDL8UArnVJA4EMtVy
YueNn6%2BbzmLGrLZJmxF6mA%3D&reserved=0>
http://www.reliableenergyanalytics.com

Email:  <mailto:dick@reliableenergyanalytics.com>
dick@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

From: Steve Lasker <Steve.Lasker@microsoft.com
<mailto:Steve.Lasker@microsoft.com> > 
Sent: Wednesday, August 10, 2022 2:22 PM
To: dick@reliableenergyanalytics.com
<mailto:dick@reliableenergyanalytics.com> ; 'Hart, Charlie'
<charlie.hart@hal.hitachi.com <mailto:charlie.hart@hal.hitachi.com> >; Orie
Steele <orie@transmute.industries <mailto:orie@transmute.industries> >
Cc: 'Steve Lasker' <Steve.Lasker=40microsoft.com@dmarc.ietf.org>;
scitt@ietf.org <mailto:scitt@ietf.org> 
Subject: RE: [SCITT] [EXT]Re: Endor: A SCITT PoC for W3C Verifiable
Credentials

 

It's an interesting example of whether a single root trust store is the best
solution. 

Just because the browser trusts a root certificate, doesn't mean it's
something we individually, or as a company believe is appropriate. We'll
just leave the specifics for obvious conclusion. 

This just points to the value of having personal, company, industry policy
based trust stores

 

From: SCITT <scitt-bounces@ietf.org <mailto:scitt-bounces@ietf.org> > On
Behalf Of Dick Brooks
Sent: Wednesday, August 3, 2022 11:26 AM
To: 'Hart, Charlie' <charlie.hart@hal.hitachi.com
<mailto:charlie.hart@hal.hitachi.com> >; Orie Steele
<orie@transmute.industries <mailto:orie@transmute.industries> >
Cc: 'Steve Lasker' <Steve.Lasker=40microsoft.com@dmarc.ietf.org
<mailto:Steve.Lasker=40microsoft.com@dmarc.ietf.org> >; scitt@ietf.org
<mailto:scitt@ietf.org> 
Subject: Re: [SCITT] [EXT]Re: Endor: A SCITT PoC for W3C Verifiable
Credentials

 

That's correct, Charlie. OATI's root cert is not included in the browser
trusted certificate store. 

 

I'm not sure why they chose to do this. 

 

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council - A Public-Private Partnership

 

 
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Freliablee
nergyanalytics.com%2Fproducts&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C
4f2be070beef426a340e08da7b0365a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
7C637957552529574280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=p%2BCeSucz3q3DY7Q2
C1EBIuZNIKsr38O7xLh7Q6278k4%3D&reserved=0> Never trust software, always
verify and report! T

 
<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.reliab
leenergyanalytics.com%2F&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C4f2be
070beef426a340e08da7b0365a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637
957552529574280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BPFQpDL8UArnVJA4EMtVy
YueNn6%2BbzmLGrLZJmxF6mA%3D&reserved=0>
http://www.reliableenergyanalytics.com

Email:  <mailto:dick@reliableenergyanalytics.com>
dick@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

From: Hart, Charlie <charlie.hart@hal.hitachi.com
<mailto:charlie.hart@hal.hitachi.com> > 
Sent: Wednesday, August 3, 2022 12:00 PM
To: 'Orie Steele' <orie@transmute.industries
<mailto:orie@transmute.industries> >; dick@reliableenergyanalytics.com
<mailto:dick@reliableenergyanalytics.com> 
Cc: 'Steve Lasker' <Steve.Lasker=40microsoft.com@dmarc.ietf.org
<mailto:Steve.Lasker=40microsoft.com@dmarc.ietf.org> >; scitt@ietf.org
<mailto:scitt@ietf.org> 
Subject: Re: [SCITT] [EXT]Re: Endor: A SCITT PoC for W3C Verifiable
Credentials

 

(Side comment: I see that OATI is not a recognized root certificate
authority by Mozilla or Apple - didn't check others - so the website is
therefore inaccessible without relaxing security.)

 

  _____  

From: SCITT <scitt-bounces@ietf.org <mailto:scitt-bounces@ietf.org> > on
behalf of Hart, Charlie <charlie.hart@hal.hitachi.com
<mailto:charlie.hart@hal.hitachi.com> >
Sent: Wednesday, August 3, 2022 11:48 AM
To: 'Orie Steele' <orie@transmute.industries
<mailto:orie@transmute.industries> >; dick@reliableenergyanalytics.com
<mailto:dick@reliableenergyanalytics.com>  <dick@reliableenergyanalytics.com
<mailto:dick@reliableenergyanalytics.com> >
Cc: 'Steve Lasker' <Steve.Lasker=40microsoft.com@dmarc.ietf.org
<mailto:Steve.Lasker=40microsoft.com@dmarc.ietf.org> >; scitt@ietf.org
<mailto:scitt@ietf.org>  <scitt@ietf.org <mailto:scitt@ietf.org> >
Subject: Re: [SCITT] [EXT]Re: Endor: A SCITT PoC for W3C Verifiable
Credentials 

 

Thanks Dick. That is really helpful for SCITT a lot of related projects I am
working on.

 

Charlie

  _____  

From: SCITT <scitt-bounces@ietf.org <mailto:scitt-bounces@ietf.org> > on
behalf of Dick Brooks <dick@reliableenergyanalytics.com
<mailto:dick@reliableenergyanalytics.com> >
Sent: Wednesday, August 3, 2022 9:26 AM
To: 'Orie Steele' <orie@transmute.industries
<mailto:orie@transmute.industries> >
Cc: 'Steve Lasker' <Steve.Lasker=40microsoft.com@dmarc.ietf.org
<mailto:Steve.Lasker=40microsoft.com@dmarc.ietf.org> >; scitt@ietf.org
<mailto:scitt@ietf.org>  <scitt@ietf.org <mailto:scitt@ietf.org> >
Subject: [EXT]Re: [SCITT] Endor: A SCITT PoC for W3C Verifiable Credentials 

 

Orie,

 

Here is a high-level overview of the authentication mechanism and tracking
used today for OASIS, inter-tie electricity scheduling.

 

Everything starts with the NAESB registry (EIR);
https://www.naesb.org/pdf4/webregistry_mo_registration_quick_ref_guide_v1.0_
0417.pdf 

 

Entities involved in inter-tie electricity transactions must register with
NAESB's EIR, see link above.

The registration process requires a party to obtain a NAESB compliant X.509
certificate from an accredited certificate authority (ACA);
https://www.naesb.org/pdf4/ac_authorities_2022.pdf

 

Entities use their digital certificates for identification in OASIS;
https://www.naesbwry.oati.com/NAESBWRY/sys-index.wml 

 

Inter-tie transactions are scheduled and tracked, using an E-TAG;
https://en.wikipedia.org/wiki/NERC_Tag 

 

E-TAG's are used to "connect the dots" and settle transactions that flow
across Balancing Authroities.

 

Hope this helps.

 

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council - A Public-Private Partnership

 

Never trust software, always verify and report! T

http://www.reliableenergyanalytics.com

Email:  <mailto:dick@reliableenergyanalytics.com>
dick@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

From: Orie Steele <orie@transmute.industries
<mailto:orie@transmute.industries> > 
Sent: Wednesday, August 3, 2022 9:09 AM
To: dick <dick@reliableenergyanalytics.com
<mailto:dick@reliableenergyanalytics.com> >
Cc: Steve Lasker <Steve.Lasker=40microsoft.com@dmarc.ietf.org
<mailto:Steve.Lasker=40microsoft.com@dmarc.ietf.org> >; scitt@ietf.org
<mailto:scitt@ietf.org> 
Subject: Re: [SCITT] Endor: A SCITT PoC for W3C Verifiable Credentials

 

Thanks! 

 

I am interested in applying Verifiable Credentials to energy use cases, even
if we don't have customers in that sector today.

The calls are open (https://github.com/w3c-ccg/traceability-vocab#meetings),
but fair warning that most of the work happens on github async, and we
usually just process issues and PRs during call time.

There are also aspects of Verifiable Credentials that I believe are relevant
to the structure of endorsements / receipts:

The concept of "evidence":

- https://www.w3.org/TR/vc-data-model/#evidence
-
https://datatracker.ietf.org/doc/html/draft-ietf-cose-countersign#section-3.
1
- https://datatracker.ietf.org/doc/html/rfc4998

 

As one example.

I am hopeful that the next version of the Verifiable Credentials
specification can point more directly to IETF RFCs to make its arguments, 
even if the json data model can't be updated to support CBOR / COSE as a
first class citizen this round.
Perhaps the next charter for that WG might support this better, if we pave
the way with examples.

Regards,

OS

 

On Wed, Aug 3, 2022, 7:54 AM Dick Brooks <dick@reliableenergyanalytics.com
<mailto:dick@reliableenergyanalytics.com> > wrote:

I agree. This paper by Orie, Michael, Brian and Mahmoud is very useful as
guide for terminology and semantics.

 

I can provide the authors with a description of how we track electricity
transactions for inter-tie scheduling, called OASIS a NAESB standard, if
interested.

 

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council - A Public-Private Partnership

 

Never trust software, always verify and report! T

http://www.reliableenergyanalytics.com

Email:  <mailto:dick@reliableenergyanalytics.com>
dick@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

From: SCITT <scitt-bounces@ietf.org <mailto:scitt-bounces@ietf.org> > On
Behalf Of Steve Lasker
Sent: Tuesday, August 2, 2022 8:21 PM
To: Orie Steele <orie@transmute.industries
<mailto:orie@transmute.industries> >; scitt@ietf.org <mailto:scitt@ietf.org>

Subject: Re: [SCITT] Endor: A SCITT PoC for W3C Verifiable Credentials

 

Very cool, Orie. 

Love the sandbox experiments

 

 

From: SCITT <scitt-bounces@ietf.org <mailto:scitt-bounces@ietf.org> > On
Behalf Of Orie Steele
Sent: Saturday, July 30, 2022 2:08 PM
To: scitt@ietf.org <mailto:scitt@ietf.org> 
Subject: [SCITT] Endor: A SCITT PoC for W3C Verifiable Credentials

 

I made this today:

https://github.com/OR13/endor

As it says in the readme, this is just a toy example I made up to experiment
with.

The nice thing about endorsing W3C Verifiable Credentials is that they are
already an abstraction that applies to "non software supply chain" use
cases... 

For example, we model cyber physical supply chain flows using them:

https://w3id.org/eability

There are a number of organizations looking at oil and gas, steel,
ecommerce, and agriculture supply chains.

Often they will share some common trade documents such as Bills of Lading or
Commercial Invoices.

These are examples of "SCITT Artifact Types" which you might expect to see
across various distinct supply chain use cases.

However, as is the case with Oil and Gas needing to account for fluid
dynamics, and software needing to account for compilers, build servers and
various source files, there are cases where you may need to model components
of a supply chain with Verifiable Credentials that are highly specific to
the use case.

If you can tolerate modeling in RDF, W3C Verifiable Credentials come with a
built in abstract data model that integrates well with existing industry
ontologies such as:

- https://www.ebi.ac.uk/chebi/
- https://qudt.org/

My main complaint against W3C Verifiable Credentials is the limitation to
JSON representations, if we could represent RDF in CBOR, we would have the
best of both worlds with the main remaining disadvantage being the namespace
overhead inherent in RDF.

If you drop that, you will likely need some registry or algorithm process
for handling collisions and interoperability, but there are various
solutions to those problems.

If you feel I butchered any of the concepts or terminology, feel free to
yell at me here or on github issues, as I said, I made this today, it's not
reflective of actual SCITT architecture, it was just to explore the space.

Regards,

OS



 

-- 

ORIE STEELE

Chief Technical Officer

www.transmute.industries