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

[Dick Brooks <[e-mail]>]

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

 

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

 

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

 

Very cool, Orie. 

Love the sandbox experiments

 

 

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

 

I made this today:

https://github.com/OR13/endor <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOR13%2Fendor&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C79cb3d326bec41bf51ac08da726fb0f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637948121310174010%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GdRRD0aMpzOJQIcqCyhajcz2NXRZH4irlRR31FFausk%3D&reserved=0> 

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ebi.ac.uk%2Fchebi%2F&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C79cb3d326bec41bf51ac08da726fb0f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637948121310174010%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bXykuDkWeLmveTLjWO5zepwu20MQ5H8LIcQJyCaKN%2BM%3D&reserved=0> 
- https://qudt.org/ <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fqudt.org%2F&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C79cb3d326bec41bf51ac08da726fb0f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637948121310174010%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QOs%2F5MIMJSm%2BkqzHSSxV6MtsA4mOIzanJ6Vwtpl4NO8%3D&reserved=0> 

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://www.transmute.industries> 

 

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