Re: [SCITT] [EXTERNAL] Re: Why not W3C Verifiable Credentials

[Maik Riechert <[e-mail]>]

I think Stephen is objecting to the fact that the issuer in VC is part of the payload instead of the signing information. In order to validate the signature, with VCs (and JWT in general) you have to reach into the payload (and decode it) to extract the issuer (the DID) in order to discover the public key used to sign.
In our model, we separate those layers more strictly, where the issuer is part of the signature envelope header and you don't have to reach into the payload to validate the signature. That's how we stay payload agnostic in SCITT. Whether that's the best strategy is another question, but it seems cleaner to do it that way in my opinion.

From: Orie Steele <[e-mail]>
Sent: Donnerstag, 21. April 2022 19:35
To: Stephen Provine <[e-mail]>
Cc: [e-mail]; Carl Wallace <[e-mail]>; Maik Riechert <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [SCITT] [EXTERNAL] Re: Why not W3C Verifiable Credentials

https://www.w3.org/TR/vc-data-model/#proofs-signatures<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fvc-data-model%2F%23proofs-signatures&data=05%7C01%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024735409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=m%2BDqfTYT2CCfOami8LTMa4npBGR3R9oGq7nMD5o%2F2tg%3D&reserved=0>

credential => a JSON-LD data model for representing complex claims that an issuer has made about a subject.

verifiable credential => a credential with an embedded or external proof that enables authentication / select disclosure / tamper protection / integrity protection of the claims made by the issuer about the subject.

It's worth remembering that these are "claims" not "objective truths"... anybody can claim anything... but claims from identifiers you trust are probably more important to you than claims from identifiers you have no details on.

When you convert the verifiable credential to a normalized form, you get a list of RDF triples of the form, subject predicate object.

Here is an example:

https://api.did.actor/v/eJylkUtzmzAAhP-LejUGhFwbTrVxk5j6RRzXj04PgEQQAYElAcYZ__cIe6bpuZ3RRZqd3f1W7-BbVDBJzhI4v0AiZSkcXW-apt9Y_YK_6tAwR3rECSZM0iATem2C3qfQovgmEySqOJWtLioqidDTRmjQgEYn_90DFAMHVJw5VUWxg5BpfrUNqNlBMNAQspEWDCJLszGKrNAYxUMcqxDZlqRr9ZNwGtMgzIj7p8fNVIiKcGWMlecbaZ2Lb4mEM_d4sp6H9byekp3_wM6XwdPix2ltewVdFOxy8Cbo5fHAYjkHd5OARWQaSBUGFK6hGaY6L6btQMuB6KhUnwNsqjAlkVrr_Q7VZZNzkJcZcUxogWsPlLwo4k5wBwCeKNiOhBv6ygJZcdLtcvdUmfgWCqFmIA2q0JEDBw6yu9D6xh0FkhZsQWRS4P9h_fIv69xQ1hUvC9GRBEIQ_ledHlD_rN5J6yXhY0RX1HvYXmbm8k3QuevRZerTVX5Mwqdlpu5plGfGLC3DWT6DS9fDsd_vJyjPMg-Fk3bf7A_TPHSNy3jsn-rlaZisBsfDebKZsNrz2fOYYgjZdO61p2jrnbYs_L5OaYOiwt3tbVRmLeQGXi3q-Rhcrx_DxvDp<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapi.did.actor%2Fv%2FeJylkUtzmzAAhP-LejUGhFwbTrVxk5j6RRzXj04PgEQQAYElAcYZ__cIe6bpuZ3RRZqd3f1W7-BbVDBJzhI4v0AiZSkcXW-apt9Y_YK_6tAwR3rECSZM0iATem2C3qfQovgmEySqOJWtLioqidDTRmjQgEYn_90DFAMHVJw5VUWxg5BpfrUNqNlBMNAQspEWDCJLszGKrNAYxUMcqxDZlqRr9ZNwGtMgzIj7p8fNVIiKcGWMlecbaZ2Lb4mEM_d4sp6H9byekp3_wM6XwdPix2ltewVdFOxy8Cbo5fHAYjkHd5OARWQaSBUGFK6hGaY6L6btQMuB6KhUnwNsqjAlkVrr_Q7VZZNzkJcZcUxogWsPlLwo4k5wBwCeKNiOhBv6ygJZcdLtcvdUmfgWCqFmIA2q0JEDBw6yu9D6xh0FkhZsQWRS4P9h_fIv69xQ1hUvC9GRBEIQ_ledHlD_rN5J6yXhY0RX1HvYXmbm8k3QuevRZerTVX5Mwqdlpu5plGfGLC3DWT6DS9fDsd_vJyjPMg-Fk3bf7A_TPHSNy3jsn-rlaZisBsfDebKZsNrz2fOYYgjZdO61p2jrnbYs_L5OaYOiwt3tbVRmLeQGXi3q-Rhcrx_DxvDp&data=05%7C01%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024735409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8H%2B2LpeqI8%2B9z%2FGwahaehpYHQFu9uW7YHsZtLTNSMsk%3D&reserved=0>

https://v.jsld.org/2QdT2VFm3qzbJcfGyUjUiMYTxq2zTWxJ1LVuNdt2V4rJUymb6uX6F1thf7v8DQqnqL9Us1iXGUEEyfQhZ3Fb5sqQ6TsDEMeyjkNsnW3fQUkzuEQR42ADtAew3nJMG7ZtwiTBR3rbPCyzDgdcMZJBTLcw8Rif7foKFXRdKq365uD4Me2U7EJ6fDQSc9qkNszp8YUcMrSHGdtdk9RMuee2ehAFk3aZo1Jthmf7jxiAL3Drz6X8MXmyePtPVB17nojyA1SH7X63U6AommqAStP5m8CRz38nVwwxVFne4JYgoBGrXZXWXXSGgpmqy3kGUzH1dSnQ6f1ZNWbhuK6vt6J8PGwiLH97EGegeRRmsaqfz2vx9q9VGfL4KCVE6W7oCYS72iLPU1XMo4s1BLZpbSBt2s9ahDUyxrNd3oJEaP2ktmB1UnvxJYE9TWUn9QXb6xLHCvrATFHs54rwcZc8brSrLKRZqb22qahQsRVQpC6ziQubJtvhC1yiVJpdJqH4Rf2Rj3XmccXa4iD9B4bE8ysjXSB8riThmYGhpB1deXdkch6XnNvTzV89qDHj4RTC2Nw1jyoEKHVRmUTAYxPiBMzMwmaTCAaqPzXeBNZ1ogYJqkyEtiAi777jsehnDN7saCdzJWqvLpTVZobHbo9UbdL4UHrNLfH13JcgLx<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fv.jsld.org%2F2QdT2VFm3qzbJcfGyUjUiMYTxq2zTWxJ1LVuNdt2V4rJUymb6uX6F1thf7v8DQqnqL9Us1iXGUEEyfQhZ3Fb5sqQ6TsDEMeyjkNsnW3fQUkzuEQR42ADtAew3nJMG7ZtwiTBR3rbPCyzDgdcMZJBTLcw8Rif7foKFXRdKq365uD4Me2U7EJ6fDQSc9qkNszp8YUcMrSHGdtdk9RMuee2ehAFk3aZo1Jthmf7jxiAL3Drz6X8MXmyePtPVB17nojyA1SH7X63U6AommqAStP5m8CRz38nVwwxVFne4JYgoBGrXZXWXXSGgpmqy3kGUzH1dSnQ6f1ZNWbhuK6vt6J8PGwiLH97EGegeRRmsaqfz2vx9q9VGfL4KCVE6W7oCYS72iLPU1XMo4s1BLZpbSBt2s9ahDUyxrNd3oJEaP2ktmB1UnvxJYE9TWUn9QXb6xLHCvrATFHs54rwcZc8brSrLKRZqb22qahQsRVQpC6ziQubJtvhC1yiVJpdJqH4Rf2Rj3XmccXa4iD9B4bE8ysjXSB8riThmYGhpB1deXdkch6XnNvTzV89qDHj4RTC2Nw1jyoEKHVRmUTAYxPiBMzMwmaTCAaqPzXeBNZ1ogYJqkyEtiAi777jsehnDN7saCdzJWqvLpTVZobHbo9UbdL4UHrNLfH13JcgLx&data=05%7C01%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024735409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=NoYWTV6IuDONaoFAhs8jEwr%2BH3b8%2BHQ4Ofz9tb4N9Cg%3D&reserved=0>

These examples use the "JSON-LD Signature" or "Embedded Proof" format... but the claims are interpreted the same regardless of the proof format.

Let's look at a few rows specifically:

<SUBJECT ID> <PREDICATE> <OBJECT>
<urn:uuid:44116902-9aa5-4494-a5c3-9d4c3b08f7df> <https://www.w3.org/2018/credentials#credentialSubject<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2018%2Fcredentials%23credentialSubject&data=05%7C01%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024735409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JlnoLBF3ODPaOdvpbWD%2FvkK9MVecZ1VE6ECQUtFN78o%3D&reserved=0>> <did:example:123> .
<urn:uuid:44116902-9aa5-4494-a5c3-9d4c3b08f7df> <https://www.w3.org/2018/credentials#issuanceDate<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2018%2Fcredentials%23issuanceDate&data=05%7C01%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024785805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=d1%2BgKTXoURaBgp5cSqVUvEmG9ba6F6cEQvt5ZpVIls4%3D&reserved=0>> "2010-01-01T19:23:24Z"^^<http://www.w3.org/2001/XMLSchema#dateTime<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23dateTime&data=05%7C01%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024785805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pv2btfpuRtsFyQI13ctH7ue7ckG8ZhKNzZ2e%2FsfRdr8%3D&reserved=0>> .
<urn:uuid:44116902-9aa5-4494-a5c3-9d4c3b08f7df> <https://www.w3.org/2018/credentials#issuer<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2018%2Fcredentials%23issuer&data=05%7C01%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024785805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UVAywofVOuJTWmpg7UN1iFNq8OaFjY3yuFLyQE3D8jQ%3D&reserved=0>> <did:key:zQ3shrnCZq3R7vLvDeWQFnxz5HMKqP9JoiMonzYJB4TGYnftL> .

First, the issuer is signing over each of these... but the issuer is the object in one of them.

That's the semantic equivalent of iss being signed over in a JWT / CWT, its a signed claim by the issuer, or the issuer's identity.

issuanceDate corresponds to the JWT nbf claim, its the date where a verifier should consider the claims about the subject to be accurate.

It's important that the issuer sign this because they may wish to "post date" credentials... similar to post dating checks.

The credential subject is basically the sub field of a JWT... that's the identifier that the issuer is claiming corresponds to the subject.

All the other claims the issuer makes about the subject will be "joined" to this identifier... but you might have a few credentials signed by different parties, that all attribute to the same subject.

Let's look at an example:

Issuer 1 claims Subject 1 has email [e-mail]<mailto:[e-mail]>
Issuer 2 claims Subject 1 has email [e-mail]<mailto:[e-mail]>

Based on this information, a verifier might not know which email is correct, but the verifier has proof of what email each issuer is claiming to be correct for that subject.

The credential is the format of the claims, the verifiable credential is the mechanism for conveying the proof.

OS

On Thu, Apr 21, 2022 at 1:05 PM Stephen Provine <[e-mail]<mailto:[e-mail]>> wrote:
Stepping back for a moment, I need help understanding why the schemas for "credential" and "verifiable credential" are tied together. Why are properties like issuer, issuance date, expiration etc. required properties in a credential?

When looking for a signature format, I expect there to be understood separation between the payload, the content to be signed (which may include the payload or a hash of the payload) and the signature over the content to be signed. I'm missing the distinction between the first two with VCs.

"Grass is green" => "Joe says Grass is green" => "Grass is green, signed Joe"

Or do we believe the author of the statement may be different to the signing identity?

"Grass is green" => "Joe says Grass is green" => "Joe says Grass is green, signed Pam"

If so, then to call "Joe" the "issuer" would be misleading. It's just another claim in the unverified credential, in this case, of authorship.

Thanks,
Stephen

From: SCITT <[e-mail]<mailto:[e-mail]>> On Behalf Of Dick Brooks
Sent: Thursday, April 21, 2022 9:47 AM
To: 'Carl Wallace' <[e-mail]<mailto:[e-mail]>>; Orie Steele <[e-mail]<mailto:[e-mail]>>; Maik Riechert <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [SCITT] [EXTERNAL] Re: Why not W3C Verifiable Credentials

Some people who received this message don't often get email from [e-mail]<mailto:[e-mail]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
The CAB/Forum has been discussing methods to address the "verifiable trust relationship" matter. From what I can tell, there is talk of a "notary" like service whereby a software consumer can verify if Party A is authorized to sign artifacts produced by Party A and Party B.

As I understand this concept A software customer can submit an inquiry to the notary service asking "Artifact Q produced by Party B is signed by party A - is this a valid trust relationship?"

Thanks,

Dick Brooks
[cid:image001.png@01D855B8.B939DC70]  [cid:image002.png@01D855B8.B939DC70]
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%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024785805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=amvSLA9qB3XzKjQiPZs2gYb42tc3roqt1oNZT6VJsAE%3D&reserved=0> (tm)
http://www.reliableenergyanalytics.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.reliableenergyanalytics.com%2F&data=05%7C01%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024785805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Uik2hibsa8mDl9N9r24jpYwHrD%2FoTHBfwdjQVohvZME%3D&reserved=0>
Email: [e-mail]<mailto:[e-mail]>
Tel: [phone]

From: Carl Wallace <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, April 21, 2022 12:38 PM
To: [e-mail]<mailto:[e-mail]>; 'Orie Steele' <[e-mail]<mailto:[e-mail]>>; 'Maik Riechert' <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [SCITT] [EXTERNAL] Re: Why not W3C Verifiable Credentials

It seems like this could be solved with a finer grained constraint associated with the public key used to verify the signature, since the issue, in part at least, is that the current constraint mechanism says "the public key can be used to verify any signed code". In addition to constraining the code signer, having constraints at trust anchor or certification authority level could help as well.

FIDO metadata (https://fidoalliance.org/metadata/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffidoalliance.org%2Fmetadata%2F&data=05%7C01%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024785805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zm%2BvirtCjBE5ywIpnjDk%2F2MZMG3mabnUs46QLMV%2FvEY%3D&reserved=0>) may be interesting comparison. Amongst other things, it contains FIDO-focused set of root certificates along with information that could be used to constrain verification of attestations via constrained TAs and CAs. Constraints of that sort may fit better for attestations due to the relatively fewer number of hardware vendors vs software vendors, but some software vendors may want their own CA or TA. The number of software vendors may motivate a transparency approach a la web PKI, with code signing certs constrained by some value that limits what it can verify and publication to a public log of all certs to detect mis-issuance.

From: SCITT <[e-mail]<mailto:[e-mail]>> on behalf of Dick Brooks <[e-mail]<mailto:[e-mail]>>
Organization: Reliable Energy Analytics LLC
Reply-To: <[e-mail]<mailto:[e-mail]>>
Date: Thursday, April 21, 2022 at 12:02 PM
To: 'Orie Steele' <[e-mail]<mailto:[e-mail]>>, 'Maik Riechert' <[e-mail]<mailto:[e-mail]>>
Cc: <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Subject: Re: [SCITT] [EXTERNAL] Re: Why not W3C Verifiable Credentials

""when" a signature from an identifier is authoritative"

This is a very slippery slope, that REA had to solve using proprietary methods in our C-SCRM software SAG-PM.

Today, using existing digital signature technologies and methods there is no "standard" method for a software consumer to verify the trust bond between the signer of a digitally signed software package and an authorized party that granted the signer authority to sign on their behalf.

https://energycentral.com/c/ec/who-ya-gonna-trust<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fenergycentral.com%2Fc%2Fec%2Fwho-ya-gonna-trust&data=05%7C01%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024785805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hkrc5C9Es5znX%2B%2F0pV16exc56oArN979jpNFUeElrcQ%3D&reserved=0>



Thanks,

Dick Brooks
[cid:image003.png@01D855B8.B939DC70]  [cid:image004.png@01D855B8.B939DC70]
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%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024785805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=amvSLA9qB3XzKjQiPZs2gYb42tc3roqt1oNZT6VJsAE%3D&reserved=0> (tm)
http://www.reliableenergyanalytics.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.reliableenergyanalytics.com%2F&data=05%7C01%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024785805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Uik2hibsa8mDl9N9r24jpYwHrD%2FoTHBfwdjQVohvZME%3D&reserved=0>
Email: [e-mail]<mailto:[e-mail]>
Tel: [phone]

From: SCITT <[e-mail]<mailto:[e-mail]>> On Behalf Of Orie Steele
Sent: Thursday, April 21, 2022 11:55 AM
To: Maik Riechert <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [SCITT] [EXTERNAL] Re: Why not W3C Verifiable Credentials

regarding "when" a signature from an identifier is authoritative... lets continue to discuss how it is related to endorsement or receipts.

On Thu, Apr 21, 2022 at 10:48 AM Maik Riechert <[e-mail]<mailto:[e-mail]>> wrote:
Thanks for the links. See the other email thread "COSE countersignatures included in authenticated data structures" for receipt discussion.

From: Orie Steele <[e-mail]<mailto:[e-mail]>>
Sent: Donnerstag, 21. April 2022 16:41
To: Maik Riechert <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] Re: Why not W3C Verifiable Credentials

You are asserting this is the format of the returned receipt?

https://datatracker.ietf.org/doc/html/draft-ietf-cose-countersign<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-cose-countersign&data=05%7C01%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024785805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=o%2FpL35bsgHRgBOm4ZmxuLcvjVcQsJMst5jfj5%2Fg%2B8J4%3D&reserved=0>

On Thu, Apr 21, 2022 at 10:15 AM Orie Steele <[e-mail]<mailto:[e-mail]>> wrote:
Another thing to keep an eye on is https://github.com/json-web-proofs/json-web-proofs<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjson-web-proofs%2Fjson-web-proofs&data=05%7C01%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024785805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ejU6aSXxKQOpDkK%2FBILv%2Fys3xJpgSoNLpEcWMa1S4t0%3D&reserved=0>

On Thu, Apr 21, 2022 at 10:13 AM Orie Steele <[e-mail]<mailto:[e-mail]>> wrote:

Here is an example of a software supply chain VC: https://w3c-ccg.github.io/traceability-vocab/#SoftwareBillOfMaterials<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c-ccg.github.io%2Ftraceability-vocab%2F%23SoftwareBillOfMaterials&data=05%7C01%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024785805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z2U838SzaKsYll%2Bn%2BcnjONKysYzNuA8nrUWezfGZC70%3D&reserved=0>

On Thu, Apr 21, 2022 at 9:52 AM Maik Riechert <[e-mail]<mailto:[e-mail]>> wrote:
Hi all,

One of the questions that came up in discussions was why SCITT doesn't use W3C Verifiable Credentials (VC) as claim format, giving that we use W3C DID, which comes from the same area.

>From my point of view, the main reason is that SCITT wants to stay agnostic on the payload type (claim format) and rather standardize on the signing envelope (so one level up). In practice, this means that for example a JSON-SPDX document [1] or an in-toto Statement [2] can be represented and signed as-is in a SCITT envelope (here, based on COSE).

Staying payload agnostic allows for a natural evolution of claim formats. The content type within the envelope identifies the format unambiguously. The idea is that over time a few popular formats emerge and are supported by downstream services.

The W3C VC spec [3] defines "credential" as the claims (JSON) and then "verifiable credential" as the claims that come with proof (either JWT or Data Integrity Proofs (based on JSON canonicalization)). Since SCITT is payload type agnostic, a SCITT envelope can contain such a "credential". The only thing missing is a registered content type.

Any feedback from the community on this topic is welcome.

Maik

[1] https://github.com/spdx/spdx-spec<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fspdx%2Fspdx-spec&data=05%7C01%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024785805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=g6wmyHnfRjHfAyK5ZWGWJvQNZ1quIL8WqM0J6e8Z2U4%3D&reserved=0>
[2] https://github.com/in-toto/attestation/blob/main/spec/README.md#statement<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fin-toto%2Fattestation%2Fblob%2Fmain%2Fspec%2FREADME.md%23statement&data=05%7C01%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024835556%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gDTnfxV%2Fh1awL1R1mpDXCUFfNberfLrzoKdsAiEAgf0%3D&reserved=0>
[3] https://www.w3.org/TR/vc-data-model<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fvc-data-model&data=05%7C01%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024835556%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XTEg92PuZlmjYE%2BG2yffvL7vYd1CKbAljjziaS0bzmw%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%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024835556%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Eq0RyM20r8QuS2OLWP2eRbt9scupL3qDpaPToL51ZmA%3D&reserved=0>

[Image removed by sender.]<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024835556%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Ck15IO10WL4e%2FPUTIi%2FY8qSP7JNiRYWLUR6hySM8IHI%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%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024835556%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Eq0RyM20r8QuS2OLWP2eRbt9scupL3qDpaPToL51ZmA%3D&reserved=0>

[Image removed by sender.]<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024835556%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Ck15IO10WL4e%2FPUTIi%2FY8qSP7JNiRYWLUR6hySM8IHI%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%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024835556%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Eq0RyM20r8QuS2OLWP2eRbt9scupL3qDpaPToL51ZmA%3D&reserved=0>

[Image removed by sender.]<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024835556%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Ck15IO10WL4e%2FPUTIi%2FY8qSP7JNiRYWLUR6hySM8IHI%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%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024835556%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Eq0RyM20r8QuS2OLWP2eRbt9scupL3qDpaPToL51ZmA%3D&reserved=0>

[Image removed by sender.]<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024835556%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Ck15IO10WL4e%2FPUTIi%2FY8qSP7JNiRYWLUR6hySM8IHI%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%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024835556%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1pPn7FLCtn0ikdTrr4RB3tkmRpn6LZr%2Foi4UfxAxyyQ%3D&reserved=0>


--
ORIE STEELE
Chief Technical Officer
www.transmute.industries<http://www.transmute.industries>

[https://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7CMaik.Riechert%40microsoft.com%7C8441bca9a48f40f6374e08da23c5a1a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637861629024835556%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Ck15IO10WL4e%2FPUTIi%2FY8qSP7JNiRYWLUR6hySM8IHI%3D&reserved=0>