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

[Dick Brooks <[e-mail]>]

Ultimately, we need to give customers the ability to verify that an artifact in their possession, i.e. a SW Package called SW-A produced by party A, can be verified as trustworthy by validating the trust relationship between party A, SW-A, and a signing party S is indeed an authorized and valid trust relationship, such that A and S cannot deny their trusted bond, expressed in the SW-A artifact.

 

Today, people have to do this work using proprietary methods that don’t scale as well as we would like and are constrained by the flaws present in the existing digital signing ecosystem.

 

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! ™

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

Email:  <mailto:[e-mail]> [e-mail]

Tel: [phone]

 

From: ProSapien Sam Smith <[e-mail]> 
Sent: Tuesday, August 16, 2022 2:32 PM
To: Steve Lasker <Steve.Lasker=[e-mail]>
Cc: [e-mail]; Carl Wallace <[e-mail]>; Orie Steele <[e-mail]>; [e-mail]
Subject: Re: [SCITT] [EXT]Re: Endor: A SCITT PoC for W3C Verifiable Credentials

 

One solution to this class of problems is to use a Web-of-Trust approach with reputable trust anchors. 

For example the GLEIF (Global Legal Entity Identifier Foundation) is setting up a trust anchor where using a type of verifiable credential, they can make an attestation that a given cryptonymous identifier controlled by a set of (public, private) key pairs is associated with a given Legal Entity. Authorized Qualified Issuers perform identity assurance and identity authentication as a precursor to issuing those credentials. This provides a Global cryptographically verifiable mechanism for establishing that any attestions by Wabbit networks my be securely attributed to authorized representatives of Wabbit Networks.  

 

Using the same open source protocols and libraries (KERI/ACDC) as that used by GLEIF any ecosystem can set up their own root-of-trust for a trust anchor to provide a complementary establishment (instead of or in addition to) GLEIF's.  The underlying protocols support provenance chains-of-authority for any issued credential (indeed trees not just chains) so that the secure attribution problem is solved.

 

So a way to address this in the SCITT working group is to accept these types of provenancing for secure attribution and then focus on supply chain specific schema and formats for managing supply chains given a solution  to the secure attribution problem.

 

See https://keri.one/keri-resources/

 





On 16 Aug 2022, at 12:19 , Steve Lasker <Steve.Lasker=[e-mail] <mailto:Steve.Lasker=[e-mail]> > wrote:

 

Thanks Carl,

I’m trying to understand your question. 

*	In your example, how does ACME rockets know the artifact is a genuine product of Wabbit Networks? Current code signing mechanisms don’t achieve this (as Dick has noted). Ideally, public keys would not be trusted for a broader context than is actually necessary.

 

If the Wabbit Networks public key isn’t trusted, what are you suggesting?

 

The opt-in model for policy would/could be, ACME Rockets decides which identities they trust, through their trust policies. They may choose to trust only X.509 public keys. But, they can also specify which public keys they trust. For instance, they might trust content signed by Docker Inc, Wabbit Networks and Microsoft. If they attempt to import something from evilco, it’s denied by default. Even if evilco got a valid public certificate, import would still be denied. This is also where DiD would come in. Within the eNotary, based on the policy, ACME rockets confirms the Wabbit Networks identity is valid, at the time of evaluation.

 

*	A goal of the spec I referenced is representation of trust anchors along with constraints on usage.

Awesome, yes, we need a solid pattern for enforcing constraints. The identity is the pre-filter to say content is signed by identities I trust. Now, lets confirm it matches the requirements.

 

 

*	…ACME Rockets doesn’t get to choose what key Wabbit Networks used to sign something,

I’m not sure I follow this. Wabbit Networks will publish their public keys. Through DiD, the signed artifact should identify where to find the public key, which the consumers can opt-into levels of that chain.

 

I do agree there’s a lot of alignment with RATS we should continue to look at and see what can be shared. We definitely want to build atop proven work.

 

From: Dick Brooks < <mailto:[e-mail]> [e-mail]> 
Sent: Tuesday, August 16, 2022 5:51 AM
To: 'Carl Wallace' < <mailto:[e-mail]> [e-mail]>; Steve Lasker < <mailto:[e-mail]> [e-mail]>; Orie Steele < <mailto:[e-mail]> [e-mail]>
Cc:  <mailto:[e-mail]> [e-mail]
Subject: RE: [SCITT] [EXT]Re: Endor: A SCITT PoC for W3C Verifiable Credentials

 

+1 to Carl’s statement: “[CW] OK. But ACME still needs to get its bearings to trust the signature from Wabbit Networks. There may be compliance programs where a digital letter of approval is generated as well, in which case ACME Rockets need not be the authority.”

 

IMO, SCITT provide the opportunity to provide customers with the ability to verify the authorized trust relationship between an artifact owner and an artifact signer.

 

We currently use the SHA256 Hash value of an artifact and the X.509 Thumbprint or PGP fingerprint of the digital signature to search for trust declarations in SAG-CTR.

 

Thanks,

 

Dick Brooks

<image004.png>  <image005.png>

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%2Freliableenergyanalytics.com%2Fproducts&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C6b311c611f2543ec539d08da7f860c56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637962511885206772%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bqjKrd%2Fi9hMxKTy00u81QhTRmthzng%2FPXWnueiyLtv4%3D&reserved=0> Never trust software, always verify and report! ™

 <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.reliableenergyanalytics.com%2F&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C6b311c611f2543ec539d08da7f860c56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637962511885362159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=doXFEcZmGr0vcZfSnxUudaB%2BDMOfFDyh4wlV7JtkbXg%3D&reserved=0> http://www.reliableenergyanalytics.com

Email:  <mailto:[e-mail]> [e-mail]

Tel: [phone]

 

From: Carl Wallace < <mailto:[e-mail]> [e-mail]> 
Sent: Tuesday, August 16, 2022 7:10 AM
To: Steve Lasker < <mailto:[e-mail]> [e-mail]>;  <mailto:[e-mail]> [e-mail]; Orie Steele < <mailto:[e-mail]> [e-mail]>
Cc:  <mailto:[e-mail]> [e-mail]
Subject: Re: [SCITT] [EXT]Re: Endor: A SCITT PoC for W3C Verifiable Credentials

 

Inline…

 

From: Steve Lasker < <mailto:[e-mail]> [e-mail]>
Date: Monday, August 15, 2022 at 12:25 PM
To: Carl Wallace < <mailto:[e-mail]> [e-mail]>, " <mailto:[e-mail]> [e-mail]" < <mailto:[e-mail]> [e-mail]>, Orie Steele < <mailto:[e-mail]> [e-mail]>
Cc: " <mailto:[e-mail]> [e-mail]" < <mailto:[e-mail]> [e-mail]>
Subject: RE: [SCITT] [EXT]Re: Endor: A SCITT PoC for W3C Verifiable Credentials

 

Thanks Carl,

*	The code signing example has cropped up here fairly often (i.e., why should my code signing key be accepted as fit to verify a signature on some other company’s code).

 

Parsing this a bit more. I believe we’re talking about the promotion scenario. Where entity B consumes artifacts from Entity A. In the Notary v2 scenarios, we talk about Wabbit Networks as an ISV, and ACME Rockets as a consumer of the software.

 

When ACME Rockets consumes the net-monitor:v1 software from the Wabbit Networks public endpoint, how do services within ACME rockets know the artifact was approved for internal usage?

 

[CW] Thank you for the example as this clearly illustrates we are talking about different things. In your example, how does ACME rockets know the artifact is a genuine product of Wabbit Networks? Current code signing mechanisms don’t achieve this (as Dick has noted). Ideally, public keys would not be trusted for a broader context than is actually necessary.

 

One solution is simply adding an ACME Rockets signature to the net-monitor:v1 software. Then, internal systems only need to check if an ACME Rockets signature exists, and it would be approved. This is overly simplistic. With SCITT, we can now add “context” to what scenarios/environments the net-monitor:v1 software was approved for use within ACME Rockets.

The premise is consumers within ACME Rockets check for a specific claim/attestation/endorsement to allow the artifact to pass a check. However, the filter on the claims check is based on a set of approved identities. For instance, if Wabbit Networks says it passes ABC123 compliance, that’s nice, but it wouldn’t pass the check. Only claims from ACME Rockets for ABC123 compliance would be allowed to pass.

 

So, the identity is a pre-filter to a set of claims/attestations/endorsements.

 

[CW] OK. But ACME still needs to get its bearings to trust the signature from Wabbit Networks. There may be compliance programs where a digital letter of approval is generated as well, in which case ACME Rockets need not be the authority.

 

------

 

*	We’ll need a means to correlate the multiples, as how do they merge.
*	[CW] I’m not following why we would merge collections. Selecting a collection for use seems more likely.

 

How would we support a company that has multiple trusts policies they need to support? There may be a company wide policy, and a department specific policy. Or, there may be an industry policy and a company specific policy. When additive, these are easy. When overlapping, how do we define the resolution of conflicting deny/accept policies?

 

[CW] Each of these polices describing what is fit for internal use may require proof of origin, integrity, etc. before the ACME Rockets’ signature is applied. A goal of the spec I referenced is representation of trust anchors along with constraints on usage. These constraints would apply to CAs and end entities, if any, and be used by relying parties. In this case, the component that applies the ACME signature would be a relying party. ACME Rockets doesn’t get to choose what key Wabbit Networks used to sign something, but can enforce constraints on the usage of public keys to limit damage if the corresponding private key is ever stolen (so that they don’t consume a net-monitor:v1 that purports to be from Wabbit Networks but was signed by Coyote, Inc.). Expressing/enforcing constraints is the hard part. The spec is loosely based on the FIDO metadata syntax, where authenticator values provide a clean target. At present it uses identifiers, claims, etc. from various specs related to the RATS working group, but is a work in progress.

 

 

From: Carl Wallace < <mailto:[e-mail]> [e-mail]> 
Sent: Friday, August 12, 2022 3:55 AM
To: Steve Lasker < <mailto:[e-mail]> [e-mail]>;  <mailto:[e-mail]> [e-mail]; Orie Steele < <mailto:[e-mail]> [e-mail]>
Cc:  <mailto:[e-mail]> [e-mail]; Steve Lasker < <mailto:[e-mail]> [e-mail]>
Subject: Re: [SCITT] [EXT]Re: Endor: A SCITT PoC for W3C Verifiable Credentials

 

Inline…

 

From: Steve Lasker < <mailto:[e-mail]> [e-mail]>
Date: Thursday, August 11, 2022 at 7:20 PM
To: " <mailto:[e-mail]> [e-mail]" < <mailto:[e-mail]> [e-mail]>, 'Carl Wallace' < <mailto:[e-mail]> [e-mail]>, Orie Steele < <mailto:[e-mail]> [e-mail]>
Cc: " <mailto:[e-mail]> [e-mail]" < <mailto:[e-mail]> [e-mail]>, 'Steve Lasker' < <mailto:Steve.Lasker=[e-mail]> Steve.Lasker=[e-mail]>
Subject: RE: [SCITT] [EXT]Re: Endor: A SCITT PoC for W3C Verifiable Credentials

 

Hi Carl, you bring up a great point that I should have clarified.

There roots of trust should be a collection. 

 

[CW] My point was more that even where there is a collection and it is possible to (tightly) bound the scope of a trust anchor or any public key then we should. The code signing example has cropped up here fairly often (i.e., why should my code signing key be accepted as fit to verify a signature on some other company’s code). FIDO attestation roots suggest that at least in some cases per-company TAs/CAs are the norm. TAs/CAs could be constrained to codify that practice.

 

You may choose to have a “public/vertical” trust policy, and an internal team “trust policy”.

We’ll need a means to correlate the multiples, as how do they merge.

 

[CW] I’m not following why we would merge collections. Selecting a collection for use seems more likely.

 

Dick – yup. It’s interesting to think about how a company stamps their security stamp, and how it relates to the sources they allow in.

 

From: SCITT < <mailto:[e-mail]> [e-mail]> On Behalf Of Dick Brooks
Sent: Thursday, August 11, 2022 6:10 AM
To: 'Carl Wallace' < <mailto:[e-mail]> [e-mail]>; Orie Steele < <mailto:[e-mail]> [e-mail]>; Steve Lasker < <mailto:[e-mail]> [e-mail]>
Cc:  <mailto:[e-mail]> [e-mail]; 'Steve Lasker' < <mailto:Steve.Lasker=[e-mail]> Steve.Lasker=[e-mail]>
Subject: Re: [SCITT] [EXT]Re: Endor: A SCITT PoC for W3C Verifiable Credentials

 

Just like other entities in the sw supply chain, the entity providing the root of trust can impact the trustworthiness score of software.

 

Thanks,

 

Dick Brooks

<image006.png>  <image007.png>

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%2Freliableenergyanalytics.com%2Fproducts&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C6b311c611f2543ec539d08da7f860c56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637962511885362159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tPF8XgTE5JuysNvZ1JbKANGDn2fsopow0LyOMwTYoWE%3D&reserved=0> Never trust software, always verify and report! ™

 <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.reliableenergyanalytics.com%2F&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C6b311c611f2543ec539d08da7f860c56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637962511885362159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=doXFEcZmGr0vcZfSnxUudaB%2BDMOfFDyh4wlV7JtkbXg%3D&reserved=0> http://www.reliableenergyanalytics.com

Email:  <mailto:[e-mail]> [e-mail]

Tel: [phone]

 

From: Carl Wallace < <mailto:[e-mail]> [e-mail]> 
Sent: Thursday, August 11, 2022 7:22 AM
To: Orie Steele < <mailto:[e-mail]> [e-mail]>; Steve Lasker < <mailto:[e-mail]> [e-mail]>
Cc:  <mailto:[e-mail]> [e-mail]; Steve Lasker < <mailto:Steve.Lasker=[e-mail]> Steve.Lasker=[e-mail]>;  <mailto:[e-mail]> [e-mail]
Subject: Re: [SCITT] [EXT]Re: Endor: A SCITT PoC for W3C Verifiable Credentials

 

A single “trust store” may or may not suffice, but we likely want to put some fences around each trust anchor to limit what the trust anchor may be used to verify.

 

The FIDO metadata alliance has method of organizing trust anchors based on authenticator type:  <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffidoalliance.org%2Fspecs%2Fmds%2Ffido-metadata-statement-v3.0-ps-20210518.html&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C6b311c611f2543ec539d08da7f860c56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637962511885362159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Ql3P%2Fw4YgjuOBMxOocirGmwK%2F3uCUbjjUNDSjDulWyQ%3D&reserved=0> https://fidoalliance.org/specs/mds/fido-metadata-statement-v3.0-ps-20210518.html.

 

I briefed this new spec to the RATS working group last month:  <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-wallace-rats-concise-ta-stores-00&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C6b311c611f2543ec539d08da7f860c56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637962511885362159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3W7bzUGQDFeqIwbl6WxnRzNqo2AFuPpEFOs3ev%2FOgzg%3D&reserved=0> https://datatracker.ietf.org/doc/html/draft-wallace-rats-concise-ta-stores-00. There’s a fork of the Veraison project’s Corim repo with support for the -00 draft added here:  <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcarl-wallace%2Fcorim&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C6b311c611f2543ec539d08da7f860c56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637962511885362159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lg4yz1OYe4GXDw5jGikXbLXRljxpwPwPVyu0o4OuLKs%3D&reserved=0> https://github.com/carl-wallace/corim. I’d imagine the environment and constraints parts move a bit still, but the rough idea may be what you are getting at below.

 

 

From: SCITT < <mailto:[e-mail]> [e-mail]> on behalf of Orie Steele < <mailto:[e-mail]> [e-mail]>
Date: Wednesday, August 10, 2022 at 2:30 PM
To: Steve Lasker < <mailto:[e-mail]> [e-mail]>
Cc: " <mailto:[e-mail]> [e-mail]" < <mailto:[e-mail]> [e-mail]>, Steve Lasker < <mailto:Steve.Lasker=[e-mail]> Steve.Lasker=[e-mail]>, " <mailto:[e-mail]> [e-mail]" < <mailto:[e-mail]> [e-mail]>
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://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%40microsoft.com%7C6b311c611f2543ec539d08da7f860c56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637962511885362159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sw7t1Bdfm%2B7nvE6%2Bl8Vc2wR1bLa7OhsttIKjyUDiX3A%3D&reserved=0> https://www.iata.org/en/pressroom/pr/2020-12-16-01/ (aviation / travel)
-  <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvci.org%2Fissuers&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C6b311c611f2543ec539d08da7f860c56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637962511885362159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JsVVzbbUlwe7ndd6xZLm8jdLFdyzYBSgG%2Biie8xySjk%3D&reserved=0> https://vci.org/issuers (healthcare)
-  <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.apple.com%2Fguide%2Fkeychain-access%2Fwhat-is-keychain-access-kyca1083%2Fmac&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C6b311c611f2543ec539d08da7f860c56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637962511885362159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=52PjlJal8dAEwGwSCuBYbP7SzFzLG1wzDppW%2BM3MLmE%3D&reserved=0> https://support.apple.com/guide/keychain-access/what-is-keychain-access-kyca1083/mac (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

 

On Wed, Aug 10, 2022 at 1:21 PM Steve Lasker < <mailto:[e-mail]> [e-mail]> wrote:

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 < <mailto:[e-mail]> [e-mail]> On Behalf Of Dick Brooks
Sent: Wednesday, August 3, 2022 11:26 AM
To: 'Hart, Charlie' < <mailto:[e-mail]> [e-mail]>; Orie Steele < <mailto:[e-mail]> [e-mail]>
Cc: 'Steve Lasker' <Steve.Lasker= <mailto:[e-mail]> [e-mail]>;  <mailto:[e-mail]> [e-mail]
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

<image008.png>  <image007.png>

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%2Freliableenergyanalytics.com%2Fproducts&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C6b311c611f2543ec539d08da7f860c56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637962511885362159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tPF8XgTE5JuysNvZ1JbKANGDn2fsopow0LyOMwTYoWE%3D&reserved=0> Never trust software, always verify and report! ™

 <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.reliableenergyanalytics.com%2F&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C6b311c611f2543ec539d08da7f860c56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637962511885362159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=doXFEcZmGr0vcZfSnxUudaB%2BDMOfFDyh4wlV7JtkbXg%3D&reserved=0> http://www.reliableenergyanalytics.com

Email:  <mailto:[e-mail]> [e-mail]

Tel: [phone]

 

From: Hart, Charlie < <mailto:[e-mail]> [e-mail]> 
Sent: Wednesday, August 3, 2022 12:00 PM
To: 'Orie Steele' < <mailto:[e-mail]> [e-mail]>;  <mailto:[e-mail]> [e-mail]
Cc: 'Steve Lasker' < <mailto:Steve.Lasker=[e-mail]> Steve.Lasker=[e-mail]>;  <mailto:[e-mail]> [e-mail]
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 < <mailto:[e-mail]> [e-mail]> on behalf of Hart, Charlie < <mailto:[e-mail]> [e-mail]>
Sent: Wednesday, August 3, 2022 11:48 AM
To: 'Orie Steele' < <mailto:[e-mail]> [e-mail]>;  <mailto:[e-mail]> [e-mail] < <mailto:[e-mail]> [e-mail]>
Cc: 'Steve Lasker' < <mailto:Steve.Lasker=[e-mail]> Steve.Lasker=[e-mail]>;  <mailto:[e-mail]> [e-mail] < <mailto:[e-mail]> [e-mail]>
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 < <mailto:[e-mail]> [e-mail]> on behalf of Dick Brooks < <mailto:[e-mail]> [e-mail]>
Sent: Wednesday, August 3, 2022 9:26 AM
To: 'Orie Steele' < <mailto:[e-mail]> [e-mail]>
Cc: 'Steve Lasker' < <mailto:Steve.Lasker=[e-mail]> Steve.Lasker=[e-mail]>;  <mailto:[e-mail]> [e-mail] < <mailto:[e-mail]> [e-mail]>
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

<image008.png>  <image009.png>

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership

 

Never trust software, always verify and report! ™

http://www.reliableenergyanalytics.com

Email:  <mailto:[e-mail]> [e-mail]

Tel: [phone]

 

From: Orie Steele < <mailto:[e-mail]> [e-mail]> 
Sent: Wednesday, August 3, 2022 9:09 AM
To: dick < <mailto:[e-mail]> [e-mail]>
Cc: Steve Lasker < <mailto:Steve.Lasker=[e-mail]> Steve.Lasker=[e-mail]>;  <mailto:[e-mail]> [e-mail]
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 < <mailto:[e-mail]> [e-mail]> 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! ™

http://www.reliableenergyanalytics.com

Email:  <mailto:[e-mail]> [e-mail]

Tel: [phone]

 

From: SCITT < <mailto:[e-mail]> [e-mail]> On Behalf Of Steve Lasker
Sent: Tuesday, August 2, 2022 8:21 PM
To: Orie Steele < <mailto:[e-mail]> [e-mail]>;  <mailto:[e-mail]> [e-mail]
Subject: Re: [SCITT] Endor: A SCITT PoC for W3C Verifiable Credentials

 

Very cool, Orie. 

Love the sandbox experiments

 

 

From: SCITT < <mailto:[e-mail]> [e-mail]> On Behalf Of Orie Steele
Sent: Saturday, July 30, 2022 2:08 PM
To:  <mailto:[e-mail]> [e-mail]
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

 




 

-- 

ORIE STEELE

Chief Technical Officer

 <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C6b311c611f2543ec539d08da7f860c56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637962511885518391%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ly8U9HHzn47GyRF5GCHuI%2B6oVWHZUY8veXgK4KFH42c%3D&reserved=0> www.transmute.industries

 

 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C6b311c611f2543ec539d08da7f860c56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637962511885675056%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2Fh2XFjoawy1FHft6hx74jVovMxlII2QoLmRJ0eoLQcY%3D&reserved=0> 

-- SCITT mailing list  <mailto:[e-mail]> [e-mail]  <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscitt&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C6b311c611f2543ec539d08da7f860c56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637962511885675056%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=W5K%2BOBo0US0xFG1otbS4KF1YnXYgj%2FCm4zFdHCJKTOc%3D&reserved=0> https://www.ietf.org/mailman/listinfo/scitt

-- 
SCITT mailing list
 <mailto:[e-mail]> [e-mail]
 <https://www.ietf.org/mailman/listinfo/scitt> https://www.ietf.org/mailman/listinfo/scitt