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

Dick Brooks <dick@reliableenergyanalytics.com> Wed, 03 August 2022 18:25 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 D9BADC159529 for <scitt@ietfa.amsl.com>; Wed, 3 Aug 2022 11:25:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 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, SPF_NONE=0.001, T_FILL_THIS_FORM_SHORT=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 VTzZ-q8rbBau for <scitt@ietfa.amsl.com>; Wed, 3 Aug 2022 11:25:39 -0700 (PDT)
Received: from wforward1-smtp.messagingengine.com (wforward1-smtp.messagingengine.com [64.147.123.30]) (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 E885CC14CF14 for <scitt@ietf.org>; Wed, 3 Aug 2022 11:25:38 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailforward.west.internal (Postfix) with ESMTP id 3BB561AC23F9; Wed, 3 Aug 2022 14:25:37 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 03 Aug 2022 14:25:37 -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=fm3; t=1659551136; x=1659637536; bh=h+ddzIMzqYxja c6loQlyn/AfJJ3GafesrDmbXg3yxys=; b=wDKOdSJ71jV1LUnszx3jZZ6SO7t2F f6PFmlRUQUMV2w+rOqGZVFlCPTejB7bmPeqW0aDzVXUXkHkn4ZQJJcBjLU87BJnD 1T9qictQ9OhAwbyvT30G3Iy9PpYuX8fiti57JA60Ra4db+yj1r4eVmV2O4DKo9r1 CL1NYRly2EbpNl2eP2i3qJCXH6FB2dCdgOX/Z9wHL0oUoDB0EfyG6Wy3sfI/0y3T xkU7f6G0LounMp8v+0w0+3m/DN2I97Sjx4pZKlHL7eyL9n8aMmz691ewz+gAqR54 CwlXtQM52XLRFwXoGIV8M7/M+xxuCox4alYDj2btIJ7xCIXAsHTgtDFDg==
X-ME-Sender: <xms:oL3qYvrYGrMxldarfWdcHpuphZ8PwLuIxbom18CXIHiyJuRxgQar8w> <xme:oL3qYpoazXtX23G7O_wqj4o-ZRh_WwXJdoBndhM7lobZ3H6xv1iplHI70aMjt9wXL SIGIp13KG8TLTo-7A>
X-ME-Received: <xmr:oL3qYsMHkwV6BOJ_GNUDKssvB8EBrCXDVKdUEyhsL5yZsJ-DyUBip5M>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvddvjedguddvhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpehrhffvvehfjgfuffhokfggtgfothesrhdtghepvddtvdenucfhrhhomhep fdffihgtkhcuuehrohhokhhsfdcuoeguihgtkhesrhgvlhhirggslhgvvghnvghrghihrg hnrghlhihtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepueefffdvgffhteehgeff udegveeiueevhfegteevheehgeeiueeuuddvveehvefgnecuffhomhgrihhnpehrvghlih grsghlvggvnhgvrhhghigrnhgrlhihthhitghsrdgtohhmpdhnrggvshgsrdhorhhgpdgt ihhstghordgtohhmpdhorghtihdrtghomhdpfihikhhiphgvughirgdrohhrghdpghhith hhuhgsrdgtohhmpdiffedrohhrghdpihgvthhfrdhorhhgpdhouhhtlhhoohhkrdgtohhm pdiffehiugdrohhrghdpvggsihdrrggtrdhukhdpqhhuughtrdhorhhgpdhtrhgrnhhsmh huthgvrdhinhguuhhsthhrihgvshenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgr mhepmhgrihhlfhhrohhmpeguihgtkhesrhgvlhhirggslhgvvghnvghrghihrghnrghlhi htihgtshdrtghomh
X-ME-Proxy: <xmx:oL3qYi7sOv9nsU8a2kWVGQx-8mdyhrIjlP8dUK3ze4JQ-4A1_8z00Q> <xmx:oL3qYu6n83YEAvJDUzCErmkwWiL7WX-AhYAsswe9nyoVWF6nQoqLZg> <xmx:oL3qYqjw7EL3QyCH6GAp2viTmc_PweEEQgv1sqZlVhVDGkweg9g_Tg> <xmx:oL3qYkQPRk8Fd4Y0cnkPlOkXb4mxlGsk8Vy5R_jKzpoWsHiOU7NjmEM1_XI>
Feedback-ID: i57d944d0:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 3 Aug 2022 14:25:36 -0400 (EDT)
Reply-To: dick@reliableenergyanalytics.com
From: Dick Brooks <dick@reliableenergyanalytics.com>
To: "'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>
In-Reply-To: <OS3PR01MB75272702BC43C5DA50A57081D19C9@OS3PR01MB7527.jpnprd01.prod.outlook.com>
Date: Wed, 03 Aug 2022 14:25:33 -0400
Organization: Reliable Energy Analytics LLC
Message-ID: <170b01d8a766$6cf8b110$46ea1330$@reliableenergyanalytics.com>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_170C_01D8A744.E5E98210"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFW99ZsMx84Va7zOFRPyoGd1SQCTgH1aWAUAs6kgHECt6pWGgJWRmN8Ao3zJs4B8+jajq4uPdYw
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/scitt/6J2c-cAXdaSauWr7oB_354SNRaQ>
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, 03 Aug 2022 18:25:43 -0000

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://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: Hart, Charlie <charlie.hart@hal.hitachi.com> 
Sent: Wednesday, August 3, 2022 12:00 PM
To: 'Orie Steele' <orie@transmute.industries>;
dick@reliableenergyanalytics.com
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

 

(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
<https://secure-web.cisco.com/1IukwuhEQqregcVfBu_YTf7qloyu0S9CLEMvuw998GuhDf
EFcipDth2Xtizyt11QWJE_rg9tKWNdFy9sR6AYzFs5C9RVZkYIdTyO90iI560dk7KjlRPsssiji4
ni2uFgQoviKwbEitz9W0A-Jkx8qlZ-bf02dT2GpXl7-qqNgMCReV-n9bPYr7-gF7wRDuDdEpNTct
YLkQFh_ODy3F4KcLc2yzJA66rSl-AObqSJo6LSNwG5QHs27-jxMPvsyvzy25FLEf6Q2NCVCA80aj
yeRx-DLlAeVOtx8sKKHCAdqS60vvgk6XONNeacK9KVifmF7/https%3A%2F%2Fwww.naesb.org%
2Fpdf4%2Fwebregistry_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
<https://secure-web.cisco.com/1T_py857nSLdfkwTRZ1F7IUeOLa0Mr0av8bfeuUJwVfOrn
lR9B8EzOzxv92Uz4iu2yhDeR4WKL_eKK39aC0HZNHbI0L6S2ynYyf3MIqoWrhcKic931Qc8ha00D
iNeKcev3mIQGWSdmm3oQWFZZeYhZ_XBpcojw3HL66SqprENJXYRuXx_69m7-vIbXr6m_muJ25A0-
WOODvl0ZvSKLB5bCCNQHy8CETUnFlhi7KK4XlPGw6ngc0NPELIFd66qeSsonDSqajtS6_XsVDeQZ
9afWewRkWRR2CS3RPxKELdvgtWbTLdNUMEo_OVauUoZUAaf/https%3A%2F%2Fwww.naesb.org%
2Fpdf4%2Fac_authorities_2022.pdf> 

 

Entities use their digital certificates for identification in OASIS;
https://www.naesbwry.oati.com/NAESBWRY/sys-index.wml
<https://secure-web.cisco.com/1K2p4qEguxjMHN9-wdAstRzAre5VeA0Zed0mvgfndElWXB
3ORaiJPQc8AT7JJNrTMjapfMno_fFQCf0Y62gyPgnjQbEmdVMFYieaur2q043F0tN564aUJcAdmT
Bs4wbQV9V3zBPE-_4E3LKMveTRd4EEA3R0FVZKKh4vLBs4hzSu8wqJmm85OMK7l0hlniB0BYAgK4
rRAKxGyo9m2gQbGh64ogBMsxFwFgbsiArp0Y6fdpXW0-RGp2kcNruYE4OtklUzkSHLHYNwG_4xj3
QZVT0CcrM1parwb_zHxkQwcXBjyXQwqawaXGq5azf6Ymysk/https%3A%2F%2Fwww.naesbwry.o
ati.com%2FNAESBWRY%2Fsys-index.wml>  

 

Inter-tie transactions are scheduled and tracked, using an E-TAG;
https://en.wikipedia.org/wiki/NERC_Tag
<https://secure-web.cisco.com/1jg0PAl4xaAUqdpMj0XlwOYUgtyWJ8AEDByMI06i_FhGx7
hBsVedp3De0cfsLDJrOWQk0OpLsHA-LZhek33mGBHnd1yGGQeO7gyBdmpJ8iJUh1jEMhZRFRhVJl
0de4TxzOc-JCGbVPgYXa-8-oyvGUdvqCL1u0riyE5i35ZXxhgFrK5jS167ftdpGerze8DpFzv01q
-lfBzQY3KxMikI7Aq599QaeahZrP9NaHPsunaoGrxrKD2WGOgLGAbiIogZvwqD6F-rbN2lIbrdeJ
ZSVYw42P3L69rJ7XlgeaYjhgkVyPIJ1HC1whjq-NLkd-N0k/https%3A%2F%2Fen.wikipedia.o
rg%2Fwiki%2FNERC_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

 

 
<https://secure-web.cisco.com/1uy0clDWHgs8Om4IdyHuQzeSluoA8y61U3xQt6svGk4U9m
gvOzG2j87xdGPNZwfL_6NeZLyvs2RtDXbQkJ-uy5FySOKYDraC9BCS46sTnuZZuNABtffYE50uYM
3Wm6rGdSXPbIPyLIo1S9U5eKgRY62SvXzyvZStiEIy-g4zrHrqiwoZ4G2AfwJHqEMJbnR-Z8wwwL
fANn8naHWq7IhHtieZojGBeisJx2LyDGehov7fBpcHgRQuNF-I-Idh5jB6CnEp4puLs01qMMVa-d
Vd11j8FHVTLpLcooV6gqqaabRENW_QqNKXvWegEhvV1Ow4u/https%3A%2F%2Freliableenergy
analytics.com%2Fproducts> Never trust software, always verify and report! T

 
<http://secure-web.cisco.com/1GaJ6l5AOFj6kxiBsMksWncl4vuiZ-pUmsWTXCh5o60xFuI
9fXHdmN1JPI17VWNKtRAJykdCd5QOfGdmalJsZes_8gztMRvB-TvoYWb6WOAm14Usouk0VNKr4H3
1T9BT5T0w1SnOo7YCh-3jVo0P2A80_8zELCxl4Ngnjzy7TfQm5dwNV_k8eKhiVi6wwvKSudLmuLC
5ig0f-n4vQfqd3zlefh4egnP1zyrbhWoo50tuzH3ceMULrOjDHUs9QVKGe8Q74awwW_o1b6KYbqO
P7Z8sQrpBMjf_ClYd-WXRlq6NNIXX0Ncd2niPfogZIcU6Y/http%3A%2F%2Fwww.reliableener
gyanalytics.com%2F> 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
<https://secure-web.cisco.com/1HgK84MRR4bzXYAE7Niaeb8pYlkoyIfmiR0g4Dwj3DQJAh
8OlSJW5p7TckF_9U5dHGeGuxJhuDgslYxAZNOsxcRUvIxstDWa3DOjtKeNjD-_Hps6IsgjIJjvko
JM6z6RXWAtxjfWtD3HV63XpkV_CEsvexRY-o5lFOUDFBoLvOST5pm3bbQJt3vdY1-67GIT9kXmrM
YnnWWXvjuDcZkNODE1fmxIV1SYT7tQT9JveadGh5Z92HkOF2nqx92HaLeF53pxMJ1kYS8DiFQiew
lQiLm9iNH3U9ZkX9n0d4hCRmD8Sp062hKxDB9F-2b8UFejS/https%3A%2F%2Fgithub.com%2Fw
3c-ccg%2Ftraceability-vocab%23meetings> ), 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://secure-web.cisco.com/1q-6jNVM6JiTVpXBQDNrSw3REGqFIliEx86xQ3m1hKtfX3
8eVvCRSGYTej4K2SK8mdFcn2JqBZgNoMPS_rcXVBpyF1l5PmPOoFcCN-jmLI5CobgwDRSgnNTCov
BIYUYq-zsaSmiiEAjGR8kgswrCi8csy-ZzBotSGM-M-GgM63-EeON2WUp7tplgZcM0drfvbvSkPm
JNyhQ7IVz_JWZxPH45UgBXDwg3rEsIvPQjU2jV8dtlLOSr9PG4zRhRFcn9AsvFV6OrKVwmbgHSCH
ZuRW-k3T397qO__A7xJXOWprvooFuCc9y3ROkMuPUf12DNw/https%3A%2F%2Fwww.w3.org%2FT
R%2Fvc-data-model%2F%23evidence> 
-
https://datatracker.ietf.org/doc/html/draft-ietf-cose-countersign#section-3.
1
<https://secure-web.cisco.com/13CILjI0celZHQgVsa-DDsoLq4Y6By6DHs7W3LY0H0AaoP
volfKPwURAqZMWPsqbcYMf_kWUKJ-sA8NLPu8wziluBz0l68B1CFniaOfUMqbMnF6C6XI8csVpay
R5nSduP0DzdtYVrex3bRpGSYyBCgbFgdA9HbqgX48TPfCCsHHqaKMfCgJpqP1qqkn_Rvw8fRnwCn
crbvhrPVrZR2672B85djLFYzQp6QkfNZLX2m7CyYa7EPkxXYtqpqrgKQ86Yl61tsyZjFCIlMY3qa
Hk_-T7iJ8rYjvtEwV0uGSDPKFXIQ-beS1aVt3d7utZHCYYa/https%3A%2F%2Fdatatracker.ie
tf.org%2Fdoc%2Fhtml%2Fdraft-ietf-cose-countersign%23section-3.1> 
- https://datatracker.ietf.org/doc/html/rfc4998
<https://secure-web.cisco.com/17DAGq2foFEYXkhjzWI_n3yyo-dU8HMigJwlon4x4SGlq2
nwnPypo_SZZqn_HVrT0rymuTwcEF4muUKWKqsOGLkvOVa-LFd_al2zZ_lLftgtmhzFQhRFS7caOQ
JT0nf29VQs3woHnI7EoIfq1qF_87Py293jXAOIKL085OwcNuJbugCi46HG7Aoa0iPHiyavETuibY
IlyB9E0dX9ck-eC39YMnZLGZAbf_U_zNKqeI-AYJbaKiKSYOMap89Xfp9wsrscC0zBwrQyJbQeJe
X0W6bmWhWAyUuBgeHltrwzsA_eV6OT02qMLpg525iRIanpK/https%3A%2F%2Fdatatracker.ie
tf.org%2Fdoc%2Fhtml%2Frfc4998> 

 

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

 

 
<https://secure-web.cisco.com/1uy0clDWHgs8Om4IdyHuQzeSluoA8y61U3xQt6svGk4U9m
gvOzG2j87xdGPNZwfL_6NeZLyvs2RtDXbQkJ-uy5FySOKYDraC9BCS46sTnuZZuNABtffYE50uYM
3Wm6rGdSXPbIPyLIo1S9U5eKgRY62SvXzyvZStiEIy-g4zrHrqiwoZ4G2AfwJHqEMJbnR-Z8wwwL
fANn8naHWq7IhHtieZojGBeisJx2LyDGehov7fBpcHgRQuNF-I-Idh5jB6CnEp4puLs01qMMVa-d
Vd11j8FHVTLpLcooV6gqqaabRENW_QqNKXvWegEhvV1Ow4u/https%3A%2F%2Freliableenergy
analytics.com%2Fproducts> Never trust software, always verify and report! T

 
<http://secure-web.cisco.com/1GaJ6l5AOFj6kxiBsMksWncl4vuiZ-pUmsWTXCh5o60xFuI
9fXHdmN1JPI17VWNKtRAJykdCd5QOfGdmalJsZes_8gztMRvB-TvoYWb6WOAm14Usouk0VNKr4H3
1T9BT5T0w1SnOo7YCh-3jVo0P2A80_8zELCxl4Ngnjzy7TfQm5dwNV_k8eKhiVi6wwvKSudLmuLC
5ig0f-n4vQfqd3zlefh4egnP1zyrbhWoo50tuzH3ceMULrOjDHUs9QVKGe8Q74awwW_o1b6KYbqO
P7Z8sQrpBMjf_ClYd-WXRlq6NNIXX0Ncd2niPfogZIcU6Y/http%3A%2F%2Fwww.reliableener
gyanalytics.com%2F> 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
<https://secure-web.cisco.com/12vv3ms4fQAlyFEE4k1zPXuwNVQhbw5JZJG1gBL6pcqttk
VpsiI3zrO00D8muCuDxuryJz9JNlTjNav5jhFZwmrDOzf2g002uvnOa4j5zplIUKqg9fIr9y-JZ4
w5q4mXJXza6z62EHNy6BzBsjPIluYavv0fR109auX6z1titrQhnW1fmk_usfbPqwJgY780ZABU5Q
TV12sZSiHaInC4MzZokObYCrnulteZlYaIml9emeQtOkK5mYExh0HK13aas-6VpgxE3PbRyBO3h9
W_wUt3BpoaWT0QrjMaAM3NSTsiDsayitR5Pm48JR4E_wr_U/https%3A%2F%2Fw3id.org%2Feab
ility> 

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
<http://secure-web.cisco.com/1Pqu2CqEyHo4isckQh51PNnQ8tUbRhJ7fbWyn-w7XWT8mKj
JG9jHB52pzDC91cVOUDvvB6yXP7TPyKL-6KQw4nyDVUvafmadZHo9d8Ch-lC1xIGYylhkgiUeEJl
kJzb-8_bPpc3HM-numNyVUnz3wy-QWiv7Bwzc0EZvjlrk8l2zMTP7sgOAXQE64zUCay7yyWGYJm9
1CoHDytU3DDP8fEQdoS8GBRvo94T1w1wYmTEFjJWuq9_05ol76LbaYkHTQoZhRROFIusDfu9XNDv
5Ofj1Xk0y_YmZkz6KS0Mx2eClGFuUIOo_FtTiX7i0x16EI/http%3A%2F%2Fwww.transmute.in
dustries>