From nobody Sat Jul 30 14:08:44 2022 Return-Path: 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 0AE5BC157902 for ; Sat, 30 Jul 2022 14:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=transmute.industries 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 1cgj5ClOOyPK for ; Sat, 30 Jul 2022 14:08:38 -0700 (PDT) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 68C09C14CF0B for ; Sat, 30 Jul 2022 14:08:38 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id m2so580558pls.4 for ; Sat, 30 Jul 2022 14:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transmute.industries; s=google; h=mime-version:from:date:message-id:subject:to; bh=+yziAqSqNd9GiQFn/BSEA3ZVwpzTyjd78DRw+Z1XBKg=; b=nho3lap/g5vqBzhe1fDvQ86EwKLFvXFLc8XoMNYMTvanWh6krqCO7OGzWGpo7mEm9o fqwABO2KuGtEm/A/O7DmhGuB8EW0L2qzrLPlCVEGPVlvNXVdCr6GKYtnMDFVuc5Cz/BU QMSKhc9ezNTmDvRqDWRnvwhflK9WiNMVpKc6i5bnEIgXJ4aVSJ5XM9yLn15Bpimu1YxJ sBhcEhXUFX8zsS9eeefD9Ds44hmeP/vcZvGu6B3rpPlyG9NbafekmZz2QvGmtq9F49Qq R5f8cuUZsqaqfFQEweTRm3aJdUHb4Ct/+TH92vdFYl507jVNBg7C2+zEOPgsga6s9Ecv 91yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+yziAqSqNd9GiQFn/BSEA3ZVwpzTyjd78DRw+Z1XBKg=; b=P+is+65tLRtgaiM8OCY049rp9cxl+sjCSxoanfrDSWV6PHGi69L07l/z/Jg4qEE+sY 4oUn3YMJHuQLJ//AQQVD29f+mfMVsn55mnizRQRQJYzokmj9Lcc4WZwyI/d4JzfwS/T1 6bHZmA16JZnbW6sJetVz7iKl5s04Q5PHZ5Tbzglmd43+AJfe4O9IzYo5ATd+54xJHdfZ E0fhUwukILZQM0ventuC5xFOzr/Um2tPVvPOv7nizMhHCUUloZr4fuclQWwt5rs+irRi yxILxE/Mtt4vPB88p3yYGmCm3KPH7+XS7SFRCLSA/5kTXoqkMNQ2dpKC0bB9iUYLd15Q Y0Og== X-Gm-Message-State: ACgBeo16e7/S2BmbEX9W2VHqfc2cRJe5Tdivb7ClRp/PVomqv+DuV1Le rkyGzmHkkqsF4XNPVc0RLprn5KLFihz+Lrnxi48oe/46+XKxqw== X-Google-Smtp-Source: AA6agR7r+1dR4B5kYBZ5mqFeQHWUEO5QXcQxZvpMteuWy7v2nYiOrjbzm2WIhCxluKOGufH7uMUqH7fHHM0Kk2D+IT8= X-Received: by 2002:a17:902:8302:b0:16d:d74f:e5cc with SMTP id bd2-20020a170902830200b0016dd74fe5ccmr7427471plb.6.1659215317338; Sat, 30 Jul 2022 14:08:37 -0700 (PDT) MIME-Version: 1.0 From: Orie Steele Date: Sat, 30 Jul 2022 16:08:26 -0500 Message-ID: To: scitt@ietf.org Content-Type: multipart/alternative; boundary="00000000000098a0b805e50c2b21" Archived-At: Subject: [SCITT] 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2022 21:08:43 -0000 --00000000000098a0b805e50c2b21 Content-Type: text/plain; charset="UTF-8" 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/traceability 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 --00000000000098a0b805e50c2b21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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=C2=A0Credentials is that they are alre= ady an abstraction that applies to "non software supply chain" us= e cases...=C2=A0

For example, we model cyber physical supply chain f= lows using them:

https://w= 3id.org/traceability

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

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

These are examples=C2=A0of "SCITT Artifact= Types" which you might expect to see across=C2=A0various distinct sup= ply chain use cases.

However, as is the case with Oil and Gas needin= g to account=C2=A0for fluid dynamics, and software needing to account for c= ompilers, build servers and various source files, there are cases where you= may need to model components=C2=A0of a supply chain with Verifiable Creden= tials that are highly specific to the use case.

If you can tolerate = modeling in RDF, W3C Verifiable Credentials come with a built in abstract d= ata model that integrates well with existing industry ontologies such as:
-=C2=A0https://www.ebi.ac.uk= /chebi/
-=C2=A0https://qudt.org/
My main complaint against W3C Verifiable Credentials is the limitatio= n 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 nam= espace overhead inherent in RDF.

If you drop that, you will likely n= eed some registry or algorithm process for handling collisions and interope= rability, but there are various solutions=C2=A0to 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<= /b>
Chief Technical Office= r
www.transmute= .industries

= --00000000000098a0b805e50c2b21--