Re: [SCITT] Trust Anchors ... was RE: [EXT]Re: Endor: A SCITT PoC for W3C Verifiable Credentials

[Hannes Tschofenig <[e-mail]>]

Hi Carl,

> [CW] I agree limiting the number of TAs is probably the most effective tool, but if you look at TA usage for FIDO or key attestations today, many cases (if not most) are vendor-specific TAs and CAs. Why not define the TAs to codify this (without relying on the honor system)?

I think from a standardization point of view there is not so much to do. From a deployment standpoint there story is obviously different. You mention the FIDO case and there is a “meta-data service”, which theoretically provides a way to distribute information about authenticators, trust anchors and lots of other information. Distributing such information (via a protocol) is obviously useful and FIDO has defined APIs to access that database (for authorized parties). The practice is, as I understand it, that many relying parties pick the trust anchors and the authenticators they like. There is a bit of a business and “trust” aspect there too.

With regards to the specification you distributed (https://datatracker.ietf.org/doc/html/draft-wallace-rats-concise-ta-stores-00), I think it can be very helpful for a RATS-based environment.

Ciao
Hannes

From: SCITT <[e-mail]> On Behalf Of Carl Wallace
Sent: Monday, August 29, 2022 5:04 PM
To: Hannes Tschofenig <[e-mail]>; Steve Lasker <[e-mail]>; [e-mail]; Orie Steele <[e-mail]>
Cc: [e-mail]; 'Steve Lasker' <Steve.Lasker=[e-mail]>
Subject: Re: [SCITT] Trust Anchors ... was RE: [EXT]Re: Endor: A SCITT PoC for W3C Verifiable Credentials

Inline…

From: SCITT <[e-mail]<mailto:[e-mail]>> on behalf of Hannes Tschofenig <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, August 24, 2022 at 5:10 AM
To: Carl Wallace <[e-mail]<mailto:[e-mail]>>, Steve Lasker <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Orie Steele <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, 'Steve Lasker' <Steve.Lasker=[e-mail]<mailto:Steve.Lasker=[e-mail]>>
Subject: [SCITT] Trust Anchors ... was RE: [EXT]Re: Endor: A SCITT PoC for W3C Verifiable Credentials

This exchange caught my attention.

For the purpose of specifying an interoperable protocol it does not matter how a trust anchor store looks like and particularly how many trust anchors it contains. It is, of course, important when deploying the protocol in a specific vertical.

[CW] The spec I referenced does not specify a protocol but does represent how the TA store looks, mostly with an eye on putting optional fences around trust anchors so we stop treating all trust anchors as more or less 100% trusted within the context the TA store is used. Provided security considerations are satisfied, how a TA store is transported is not important nor is how an application ultimately stores TAs. The main point is expressing and enforcing limitations on use.

For example, a typical trust anchor store in a web browser for use with TLS has a large number of trust anchors (because that’s how the companies in the CA Browser Forum decided it). This trust anchor store can be (and typically is) augmented for use in enterprise environments. That does, however, not mean that the use of TLS in other environments requires the use of the same trust anchor store. The use of TLS on IoT devices, for example, use a very limited trust anchor store that is unrelated to the trust anchor store used by web browsers.

[CW] I agree limiting the number of TAs is probably the most effective tool, but if you look at TA usage for FIDO or key attestations today, many cases (if not most) are vendor-specific TAs and CAs. Why not define the TAs to codify this (without relying on the honor system)?

Ciao
Hannes

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

Inline…

From: Steve Lasker <[e-mail]<mailto:[e-mail]>>
Date: Thursday, August 11, 2022 at 7:20 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, 'Carl Wallace' <[e-mail]<mailto:[e-mail]>>, Orie Steele <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, 'Steve Lasker' <Steve.Lasker=[e-mail]<mailto: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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Dick Brooks
Sent: Thursday, August 11, 2022 6:10 AM
To: 'Carl Wallace' <[e-mail]<mailto:[e-mail]>>; Orie Steele <[e-mail]<mailto:[e-mail]>>; Steve Lasker <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; 'Steve Lasker' <Steve.Lasker=[e-mail]<mailto: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
[cid:image001.png@01D8BBCE.B8F969C0]  [cid:image002.png@01D8BBCE.B8F969C0]
Active Member of the CISA Critical Manufacturing Sector,
Sector Coordinating Council – A Public-Private Partnership

Never trust software, always verify and report!<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Freliableenergyanalytics.com%2Fproducts&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775393324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UvC3lddhcdfABVduC5lNH%2FBo9UI2mZNKNyxQR64%2F3ow%3D&reserved=0> ™
http://www.reliableenergyanalytics.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.reliableenergyanalytics.com%2F&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775393324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=e7eGrpg1XYOqxWH1r7coBhlrnFq3MCN8TllCDQvmhW8%3D&reserved=0>
Email: [e-mail]<mailto:[e-mail]>
Tel: [phone]

From: Carl Wallace <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, August 11, 2022 7:22 AM
To: Orie Steele <[e-mail]<mailto:[e-mail]>>; Steve Lasker <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Steve Lasker <Steve.Lasker=[e-mail]<mailto:Steve.Lasker=[e-mail]>>; [e-mail]<mailto:[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://fidoalliance.org/specs/mds/fido-metadata-statement-v3.0-ps-20210518.html<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%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775393324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=A1f2XHwt57dDgZg4pjsUUoGsn250CH8ILVHJPCGp160%3D&reserved=0>.

I briefed this new spec to the RATS working group last month: https://datatracker.ietf.org/doc/html/draft-wallace-rats-concise-ta-stores-00<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%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775393324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9E3eGOEU40cTanaD21j5nkHScwrfqbltdrJ6S%2F3lm%2Bc%3D&reserved=0>. There’s a fork of the Veraison project’s Corim repo with support for the -00 draft added here: https://github.com/carl-wallace/corim<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcarl-wallace%2Fcorim&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775393324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8MHSgBmYXJyt%2BzHOH7Kid%2BoVfRkHPTnqqeJ%2FcNCr738%3D&reserved=0>. 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 <[e-mail]<mailto:[e-mail]>> on behalf of Orie Steele <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, August 10, 2022 at 2:30 PM
To: Steve Lasker <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Steve Lasker <Steve.Lasker=[e-mail]<mailto:Steve.Lasker=[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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://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%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775549562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ibiFkRbk9H51QnJ60w0IHjKfyB6cBno6s866TRmFfvE%3D&reserved=0> (aviation / travel)
- https://vci.org/issuers<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvci.org%2Fissuers&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775549562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8sraYlaHSVMVSsf4TGaC5VyaK%2BHB7YQP14lCll6r%2Bpc%3D&reserved=0> (healthcare)
- https://support.apple.com/guide/keychain-access/what-is-keychain-access-kyca1083/mac<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%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775549562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iWiJOGU8oFYbiljyPGzAGqU%2FFNqQUIu2tnlx6yEHgQU%3D&reserved=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

On Wed, Aug 10, 2022 at 1:21 PM Steve Lasker <[e-mail]<mailto:[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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Dick Brooks
Sent: Wednesday, August 3, 2022 11:26 AM
To: 'Hart, Charlie' <[e-mail]<mailto:[e-mail]>>; Orie Steele <[e-mail]<mailto:[e-mail]>>
Cc: 'Steve Lasker' <Steve.Lasker=[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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
[cid:image003.png@01D8BBCE.B8F969C0]  [cid:image004.png@01D8BBCE.B8F969C0]
Active Member of the CISA Critical Manufacturing Sector,
Sector Coordinating Council – A Public-Private Partnership

Never trust software, always verify and report!<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Freliableenergyanalytics.com%2Fproducts&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775549562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZHDtHTLrITizz%2FPczCtT15%2BBFsUMO2hp4MbI%2BDCR074%3D&reserved=0> ™
http://www.reliableenergyanalytics.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.reliableenergyanalytics.com%2F&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775549562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=IkzlFvkTWM3oziqg28OLgP3OavymFEgpI7uvASgdHlA%3D&reserved=0>
Email: [e-mail]<mailto:[e-mail]>
Tel: [phone]

From: Hart, Charlie <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, August 3, 2022 12:00 PM
To: 'Orie Steele' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: 'Steve Lasker' <Steve.Lasker=[e-mail]<mailto:Steve.Lasker=[e-mail]>>; [e-mail]<mailto:[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 <[e-mail]<mailto:[e-mail]>> on behalf of Hart, Charlie <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, August 3, 2022 11:48 AM
To: 'Orie Steele' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: 'Steve Lasker' <Steve.Lasker=[e-mail]<mailto:Steve.Lasker=[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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 <[e-mail]<mailto:[e-mail]>> on behalf of Dick Brooks <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, August 3, 2022 9:26 AM
To: 'Orie Steele' <[e-mail]<mailto:[e-mail]>>
Cc: 'Steve Lasker' <Steve.Lasker=[e-mail]<mailto:Steve.Lasker=[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure-web.cisco.com%2F1IukwuhEQqregcVfBu_YTf7qloyu0S9CLEMvuw998GuhDfEFcipDth2Xtizyt11QWJE_rg9tKWNdFy9sR6AYzFs5C9RVZkYIdTyO90iI560dk7KjlRPsssiji4ni2uFgQoviKwbEitz9W0A-Jkx8qlZ-bf02dT2GpXl7-qqNgMCReV-n9bPYr7-gF7wRDuDdEpNTctYLkQFh_ODy3F4KcLc2yzJA66rSl-AObqSJo6LSNwG5QHs27-jxMPvsyvzy25FLEf6Q2NCVCA80ajyeRx-DLlAeVOtx8sKKHCAdqS60vvgk6XONNeacK9KVifmF7%2Fhttps%253A%252F%252Fwww.naesb.org%252Fpdf4%252Fwebregistry_mo_registration_quick_ref_guide_v1.0_0417.pdf&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775549562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MhDrKwDzEyGz2bNoD688LjbM50xrrTcxjDyr71GtIZA%3D&reserved=0>



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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure-web.cisco.com%2F1T_py857nSLdfkwTRZ1F7IUeOLa0Mr0av8bfeuUJwVfOrnlR9B8EzOzxv92Uz4iu2yhDeR4WKL_eKK39aC0HZNHbI0L6S2ynYyf3MIqoWrhcKic931Qc8ha00DiNeKcev3mIQGWSdmm3oQWFZZeYhZ_XBpcojw3HL66SqprENJXYRuXx_69m7-vIbXr6m_muJ25A0-WOODvl0ZvSKLB5bCCNQHy8CETUnFlhi7KK4XlPGw6ngc0NPELIFd66qeSsonDSqajtS6_XsVDeQZ9afWewRkWRR2CS3RPxKELdvgtWbTLdNUMEo_OVauUoZUAaf%2Fhttps%253A%252F%252Fwww.naesb.org%252Fpdf4%252Fac_authorities_2022.pdf&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775549562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Sz8xlBP2LKR6FnPY30P6EIzFVb7JjeOaBeC9yokQNFs%3D&reserved=0>



Entities use their digital certificates for identification in OASIS; https://www.naesbwry.oati.com/NAESBWRY/sys-index.wml<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure-web.cisco.com%2F1K2p4qEguxjMHN9-wdAstRzAre5VeA0Zed0mvgfndElWXB3ORaiJPQc8AT7JJNrTMjapfMno_fFQCf0Y62gyPgnjQbEmdVMFYieaur2q043F0tN564aUJcAdmTBs4wbQV9V3zBPE-_4E3LKMveTRd4EEA3R0FVZKKh4vLBs4hzSu8wqJmm85OMK7l0hlniB0BYAgK4rRAKxGyo9m2gQbGh64ogBMsxFwFgbsiArp0Y6fdpXW0-RGp2kcNruYE4OtklUzkSHLHYNwG_4xj3QZVT0CcrM1parwb_zHxkQwcXBjyXQwqawaXGq5azf6Ymysk%2Fhttps%253A%252F%252Fwww.naesbwry.oati.com%252FNAESBWRY%252Fsys-index.wml&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775549562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=NyH1e5qJW7q7IPJhWRzqVTo7vbnZne6TyiQoanEFMVY%3D&reserved=0>



Inter-tie transactions are scheduled and tracked, using an E-TAG; https://en.wikipedia.org/wiki/NERC_Tag<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure-web.cisco.com%2F1jg0PAl4xaAUqdpMj0XlwOYUgtyWJ8AEDByMI06i_FhGx7hBsVedp3De0cfsLDJrOWQk0OpLsHA-LZhek33mGBHnd1yGGQeO7gyBdmpJ8iJUh1jEMhZRFRhVJl0de4TxzOc-JCGbVPgYXa-8-oyvGUdvqCL1u0riyE5i35ZXxhgFrK5jS167ftdpGerze8DpFzv01q-lfBzQY3KxMikI7Aq599QaeahZrP9NaHPsunaoGrxrKD2WGOgLGAbiIogZvwqD6F-rbN2lIbrdeJZSVYw42P3L69rJ7XlgeaYjhgkVyPIJ1HC1whjq-NLkd-N0k%2Fhttps%253A%252F%252Fen.wikipedia.org%252Fwiki%252FNERC_Tag&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775549562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Kj8fZsaxFMsJXEDMOGwXtaCDTd7djPsFzGlyf%2Fdve6Q%3D&reserved=0>



E-TAG’s are used to “connect the dots” and settle transactions that flow across Balancing Authroities.



Hope this helps.



Thanks,



Dick Brooks

[cid:image003.png@01D8BBCE.B8F969C0]  [cid:image005.png@01D8BBCE.B8F969C0]

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership



Never trust software, always verify and report!<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure-web.cisco.com%2F1uy0clDWHgs8Om4IdyHuQzeSluoA8y61U3xQt6svGk4U9mgvOzG2j87xdGPNZwfL_6NeZLyvs2RtDXbQkJ-uy5FySOKYDraC9BCS46sTnuZZuNABtffYE50uYM3Wm6rGdSXPbIPyLIo1S9U5eKgRY62SvXzyvZStiEIy-g4zrHrqiwoZ4G2AfwJHqEMJbnR-Z8wwwLfANn8naHWq7IhHtieZojGBeisJx2LyDGehov7fBpcHgRQuNF-I-Idh5jB6CnEp4puLs01qMMVa-dVd11j8FHVTLpLcooV6gqqaabRENW_QqNKXvWegEhvV1Ow4u%2Fhttps%253A%252F%252Freliableenergyanalytics.com%252Fproducts&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775549562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pVj2XzmdVnb1eYbPdhXNbjVsrNkFmXP2KtZLnV4DXv0%3D&reserved=0> ™

http://www.reliableenergyanalytics.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsecure-web.cisco.com%2F1GaJ6l5AOFj6kxiBsMksWncl4vuiZ-pUmsWTXCh5o60xFuI9fXHdmN1JPI17VWNKtRAJykdCd5QOfGdmalJsZes_8gztMRvB-TvoYWb6WOAm14Usouk0VNKr4H31T9BT5T0w1SnOo7YCh-3jVo0P2A80_8zELCxl4Ngnjzy7TfQm5dwNV_k8eKhiVi6wwvKSudLmuLC5ig0f-n4vQfqd3zlefh4egnP1zyrbhWoo50tuzH3ceMULrOjDHUs9QVKGe8Q74awwW_o1b6KYbqOP7Z8sQrpBMjf_ClYd-WXRlq6NNIXX0Ncd2niPfogZIcU6Y%2Fhttp%253A%252F%252Fwww.reliableenergyanalytics.com%252F&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775549562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Vq38Nw%2FThVfv0yx6kbd8ZvGzVPTEp8G0F223vad5Vds%3D&reserved=0>

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

Tel: [phone]



From: Orie Steele <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, August 3, 2022 9:09 AM
To: dick <[e-mail]<mailto:[e-mail]>>
Cc: Steve Lasker <Steve.Lasker=[e-mail]<mailto:Steve.Lasker=[e-mail]>>; [e-mail]<mailto:[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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure-web.cisco.com%2F1HgK84MRR4bzXYAE7Niaeb8pYlkoyIfmiR0g4Dwj3DQJAh8OlSJW5p7TckF_9U5dHGeGuxJhuDgslYxAZNOsxcRUvIxstDWa3DOjtKeNjD-_Hps6IsgjIJjvkoJM6z6RXWAtxjfWtD3HV63XpkV_CEsvexRY-o5lFOUDFBoLvOST5pm3bbQJt3vdY1-67GIT9kXmrMYnnWWXvjuDcZkNODE1fmxIV1SYT7tQT9JveadGh5Z92HkOF2nqx92HaLeF53pxMJ1kYS8DiFQiewlQiLm9iNH3U9ZkX9n0d4hCRmD8Sp062hKxDB9F-2b8UFejS%2Fhttps%253A%252F%252Fgithub.com%252Fw3c-ccg%252Ftraceability-vocab%2523meetings&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775549562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=KK%2B9xg%2FDZ0V700w%2Fer7ku0EBm42sbYbu0WsM6fw0lyY%3D&reserved=0>), 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure-web.cisco.com%2F1q-6jNVM6JiTVpXBQDNrSw3REGqFIliEx86xQ3m1hKtfX38eVvCRSGYTej4K2SK8mdFcn2JqBZgNoMPS_rcXVBpyF1l5PmPOoFcCN-jmLI5CobgwDRSgnNTCovBIYUYq-zsaSmiiEAjGR8kgswrCi8csy-ZzBotSGM-M-GgM63-EeON2WUp7tplgZcM0drfvbvSkPmJNyhQ7IVz_JWZxPH45UgBXDwg3rEsIvPQjU2jV8dtlLOSr9PG4zRhRFcn9AsvFV6OrKVwmbgHSCHZuRW-k3T397qO__A7xJXOWprvooFuCc9y3ROkMuPUf12DNw%2Fhttps%253A%252F%252Fwww.w3.org%252FTR%252Fvc-data-model%252F%2523evidence&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775549562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EAKGHIwnVtiLFFcQruZihWFDZyoorQUHwgyPwMeYMLc%3D&reserved=0>
- https://datatracker.ietf.org/doc/html/draft-ietf-cose-countersign#section-3.1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure-web.cisco.com%2F13CILjI0celZHQgVsa-DDsoLq4Y6By6DHs7W3LY0H0AaoPvolfKPwURAqZMWPsqbcYMf_kWUKJ-sA8NLPu8wziluBz0l68B1CFniaOfUMqbMnF6C6XI8csVpayR5nSduP0DzdtYVrex3bRpGSYyBCgbFgdA9HbqgX48TPfCCsHHqaKMfCgJpqP1qqkn_Rvw8fRnwCncrbvhrPVrZR2672B85djLFYzQp6QkfNZLX2m7CyYa7EPkxXYtqpqrgKQ86Yl61tsyZjFCIlMY3qaHk_-T7iJ8rYjvtEwV0uGSDPKFXIQ-beS1aVt3d7utZHCYYa%2Fhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fhtml%252Fdraft-ietf-cose-countersign%2523section-3.1&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775549562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=c05Oa%2FLXCj%2BNNpC2TUpRjB5naFt%2FdWJusbYqvwzv%2B1g%3D&reserved=0>
- https://datatracker.ietf.org/doc/html/rfc4998<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure-web.cisco.com%2F17DAGq2foFEYXkhjzWI_n3yyo-dU8HMigJwlon4x4SGlq2nwnPypo_SZZqn_HVrT0rymuTwcEF4muUKWKqsOGLkvOVa-LFd_al2zZ_lLftgtmhzFQhRFS7caOQJT0nf29VQs3woHnI7EoIfq1qF_87Py293jXAOIKL085OwcNuJbugCi46HG7Aoa0iPHiyavETuibYIlyB9E0dX9ck-eC39YMnZLGZAbf_U_zNKqeI-AYJbaKiKSYOMap89Xfp9wsrscC0zBwrQyJbQeJeX0W6bmWhWAyUuBgeHltrwzsA_eV6OT02qMLpg525iRIanpK%2Fhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fhtml%252Frfc4998&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775549562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=E4cnd3kmxmJgoo9JH4RKbPVgGkelbyHAx%2FIIsS7jNNE%3D&reserved=0>



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



Never trust software, always verify and report!<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure-web.cisco.com%2F1uy0clDWHgs8Om4IdyHuQzeSluoA8y61U3xQt6svGk4U9mgvOzG2j87xdGPNZwfL_6NeZLyvs2RtDXbQkJ-uy5FySOKYDraC9BCS46sTnuZZuNABtffYE50uYM3Wm6rGdSXPbIPyLIo1S9U5eKgRY62SvXzyvZStiEIy-g4zrHrqiwoZ4G2AfwJHqEMJbnR-Z8wwwLfANn8naHWq7IhHtieZojGBeisJx2LyDGehov7fBpcHgRQuNF-I-Idh5jB6CnEp4puLs01qMMVa-dVd11j8FHVTLpLcooV6gqqaabRENW_QqNKXvWegEhvV1Ow4u%2Fhttps%253A%252F%252Freliableenergyanalytics.com%252Fproducts&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775549562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pVj2XzmdVnb1eYbPdhXNbjVsrNkFmXP2KtZLnV4DXv0%3D&reserved=0> ™

http://www.reliableenergyanalytics.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsecure-web.cisco.com%2F1GaJ6l5AOFj6kxiBsMksWncl4vuiZ-pUmsWTXCh5o60xFuI9fXHdmN1JPI17VWNKtRAJykdCd5QOfGdmalJsZes_8gztMRvB-TvoYWb6WOAm14Usouk0VNKr4H31T9BT5T0w1SnOo7YCh-3jVo0P2A80_8zELCxl4Ngnjzy7TfQm5dwNV_k8eKhiVi6wwvKSudLmuLC5ig0f-n4vQfqd3zlefh4egnP1zyrbhWoo50tuzH3ceMULrOjDHUs9QVKGe8Q74awwW_o1b6KYbqOP7Z8sQrpBMjf_ClYd-WXRlq6NNIXX0Ncd2niPfogZIcU6Y%2Fhttp%253A%252F%252Fwww.reliableenergyanalytics.com%252F&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775706779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cfhLpk6YV8EXpvYEGBFV%2Bsi%2BJdPmaoUFdoMxh%2B65eoc%3D&reserved=0>

Email: [e-mail]<mailto:[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%2Fsecure-web.cisco.com%2F1JdHGvnoZNb-fsV-unMzNkw21OKT7rRYo5H60Wa4K-Q4p7fB8jPlLTjzltfaxYOFnI68iv9RdZu4eeZzCvslBoPZThRfqgjbkIpAc_QAmXII8wXvclTmJp1PwWBck7W8vUKCgPgTPKwAgR4azwJsBLeLGe7E_NyiTmvg20gtS7omF01B7xzwXNs2jk4HRv9cwHQUOknpcyXaDoXN69mDdag7A6KlfSI3EnnlDQtYrlaKovDQmzajAmTkxfuCfWTP_pf0IHh1ylWT3YFkVxRBNLDyDNrCvdIUdSvpseyxcBy2VV7YxaRLm7g0FGZCbhIv6%2Fhttps%253A%252F%252Fnam06.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fgithub.com%25252FOR13%25252Fendor%2526data%253D05%25257C01%25257CSteve.Lasker%252540microsoft.com%25257C79cb3d326bec41bf51ac08da726fb0f1%25257C72f988bf86f141af91ab2d7cd011db47%25257C1%25257C0%25257C637948121310174010%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%25257C%25257C%25257C%2526sdata%253DGdRRD0aMpzOJQIcqCyhajcz2NXRZH4irlRR31FFausk%25253D%2526reserved%253D0&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775706779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=b8g0nbIGtiWMwt%2FbJ2e8zkOSWWT0RGL8aTJp8WSg9Vw%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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure-web.cisco.com%2F12vv3ms4fQAlyFEE4k1zPXuwNVQhbw5JZJG1gBL6pcqttkVpsiI3zrO00D8muCuDxuryJz9JNlTjNav5jhFZwmrDOzf2g002uvnOa4j5zplIUKqg9fIr9y-JZ4w5q4mXJXza6z62EHNy6BzBsjPIluYavv0fR109auX6z1titrQhnW1fmk_usfbPqwJgY780ZABU5QTV12sZSiHaInC4MzZokObYCrnulteZlYaIml9emeQtOkK5mYExh0HK13aas-6VpgxE3PbRyBO3h9W_wUt3BpoaWT0QrjMaAM3NSTsiDsayitR5Pm48JR4E_wr_U%2Fhttps%253A%252F%252Fw3id.org%252Feability&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775706779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fsRJDEB5o7tTMixhGRz5iB0eYrBU5472L7US8aQhvcU%3D&reserved=0>

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%2Fsecure-web.cisco.com%2F1xFJzJsWalPbOckWorQVNuB3cCxcqr_4Pnqdh8BSqQrkm5N_-bHyC7w5_vXmkyt3-yiVfIj2Taw61Ngm4aT3AjD2Qv9jcxLAp632sCb0f7Z5opQ1IopQYFh035H3GJnum5M15fE7-kYGBh8eU24y4DJKQAGfZ6-2bMGAFBVdqq-7OCluOKHpJ7klc1xO775JEUod25j8sSRq32VCH023VBaqj9QgsfC-48IxN6LcJbg6jK3GgYWuUW9etiMl5z6YA0zskfxChMC6yEEFi8jPu3jPIy1SKm5Zu3HDbk7_-aS_gzJ-Kg45rGJrtq0L6Yh9Y%2Fhttps%253A%252F%252Fnam06.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fwww.ebi.ac.uk%25252Fchebi%25252F%2526data%253D05%25257C01%25257CSteve.Lasker%252540microsoft.com%25257C79cb3d326bec41bf51ac08da726fb0f1%25257C72f988bf86f141af91ab2d7cd011db47%25257C1%25257C0%25257C637948121310174010%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%25257C%25257C%25257C%2526sdata%253DbXykuDkWeLmveTLjWO5zepwu20MQ5H8LIcQJyCaKN%25252BM%25253D%2526reserved%253D0&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775706779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rfO%2BSOnmZkZ7E5OGI8N%2FNct6xjj6PZAwaXh%2BoOBxgtY%3D&reserved=0>
- https://qudt.org/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure-web.cisco.com%2F1wTZmUTRG0X-fSLt6dzZoQCNorRuSvOgI2Zkd9g1PT-Iict4ikGg0GMZvBAIgZsC1maaOAyMgHegWdFG3dXEcQrYKnrjpiOl7OWCtiRGcjVJC4W7PiyfkrkoEDMc-WVzXjqIc3RTjhCVEO2Hy1KcH5Xg8lqTshdNo9NGPllnHT63UctpLAAQ4N8tGBMfu3q7YUicxI0zcgap8yD60I8HL33SfI2MFnr2DphA42faHPK6e5mePI5N1MZuhmdt3ou2MvF4zqUj9xhZGwb3nRkquaaObQFWXt8G-nog2o8iwaQFLpUTsPJbOJlpOLnLalkAL%2Fhttps%253A%252F%252Fnam06.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fqudt.org%25252F%2526data%253D05%25257C01%25257CSteve.Lasker%252540microsoft.com%25257C79cb3d326bec41bf51ac08da726fb0f1%25257C72f988bf86f141af91ab2d7cd011db47%25257C1%25257C0%25257C637948121310174010%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%25257C%25257C%25257C%2526sdata%253DQOs%25252F5MIMJSm%25252BkqzHSSxV6MtsA4mOIzanJ6Vwtpl4NO8%25253D%2526reserved%253D0&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775706779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=y6RFq954c3hb9dCHw08Akb1oSFFVyHKAwPHoD21Ij%2Bw%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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsecure-web.cisco.com%2F1Pqu2CqEyHo4isckQh51PNnQ8tUbRhJ7fbWyn-w7XWT8mKjJG9jHB52pzDC91cVOUDvvB6yXP7TPyKL-6KQw4nyDVUvafmadZHo9d8Ch-lC1xIGYylhkgiUeEJlkJzb-8_bPpc3HM-numNyVUnz3wy-QWiv7Bwzc0EZvjlrk8l2zMTP7sgOAXQE64zUCay7yyWGYJm91CoHDytU3DDP8fEQdoS8GBRvo94T1w1wYmTEFjJWuq9_05ol76LbaYkHTQoZhRROFIusDfu9XNDv5Ofj1Xk0y_YmZkz6KS0Mx2eClGFuUIOo_FtTiX7i0x16EI%2Fhttp%253A%252F%252Fwww.transmute.industries&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775706779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mjTvTG60lIldnjzEwdKmQLPpPSsSK5fHpQpBJrA2nyg%3D&reserved=0>




--
ORIE STEELE
Chief Technical Officer
www.transmute.industries<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775706779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=e6USIBjbcStBP3zjxdjLcxluFj4tVWbiHGxnaVRd84M%3D&reserved=0>

[Image removed by sender.]<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775706779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=geFkZhGDl2Wo9D5cHVHB5hY5N%2B2qSxAtS8IFsowfA6k%3D&reserved=0>
-- SCITT mailing list [e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/scitt<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscitt&data=05%7C01%7CSteve.Lasker%40microsoft.com%7C620664d7e9384a9e876908da7b9acc40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637958202775706779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=03IVV7ZE7hVLSD3apB5FFFXAHANiiMNeAcac3IQ7tfg%3D&reserved=0>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
-- SCITT mailing list [e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/scitt
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.