RE: VC Evidence Discussion

In https://w3c-ccg.github.io/traceability-vocab/, there appears to be a 4th option: relatedDocuments.

Related *Link* appears to be used for “links” as in relationships while related “Documents” appears to be used for embedded data/documents (based on the examples where it appears).

Neither relatedLink nor relatedDocuments are defined in the https://w3c-ccg.github.io/traceability-vocab/ (or https://www.w3.org/TR/vc-data-model/) documents.

Michael

From: Mahmoud Alkhraishi <mahmoud@mavennet.com>
Sent: Sunday, April 10, 2022 11:27 AM
To: Morgan Hedges <morgan.hedges@gosource.com.au>; Orie Steele <orie@transmute.industries>
Cc: Steve Capell <steve.capell@gmail.com>; Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>; Kerri Lemoie <klemoie@concentricsky.com>; W3C Credentials CG (Public List) <public-credentials@w3.org>; public-vc-edu@w3.org
Subject: Re: VC Evidence Discussion

Hi All,

As Orie mentioned we've been discussing evidence and its usage in supply chain use cases. One of the use cases that we're hoping it would tackle is references to other Credentials.
As an example, a credential that represents a transportation event may need to reference one or more other credentials, like a Bill of Lading Credential or a Product Credential, and you may the use cases Orie outlined:
1. You might want to change that data behind the URI without breaking the signature
2.  You might want the signature to break if the data behind it changes
3. You might want to add new data behind the URI after the credential was issued
4. The data behind the URI might be several orders of magnitude larger than the credential (like a large ML model / or training set).

The options as I currently see them are:

  1.  Use the evidence property on the transportation event
  2.  Use the Related Link property
  3.  Use hash links in either the evidence or related link properties.

for both 1 and 2, we have the ability to:

  1.  change the data behind the URI without breaking the signature including adding data or pointing to a newer context
  2.  include data in the evidence property itself that will you want to be sure does not change, like a GTIN or SKU, I believe you cannot do the same for the Related Link property but I'm happy to be corrected on this.
  3.  not include large data sets in the credential
  4.  avoid the necessity of knowing how to process hash links

For point 3 we have the ability to:

  1.  be sure the data the credential points to will not change.
  2.  not include large data sets in the credential

I'm personally leaning to point 2 looking at the current state of the evidence property, but I think a fully interoperable, and well-documented evidence property might end up being the better solution in the long run.

Regards,
Mahmoud Alkhraishi
Director of Engineering
________________________________
From: Morgan Hedges <morgan.hedges@gosource.com.au<mailto:morgan.hedges@gosource.com.au>>
Sent: Saturday, April 9, 2022 11:08 AM
To: Orie Steele <orie@transmute.industries<mailto:orie@transmute.industries>>
Cc: Steve Capell <steve.capell@gmail.com<mailto:steve.capell@gmail.com>>; Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>; Kerri Lemoie <klemoie@concentricsky.com<mailto:klemoie@concentricsky.com>>; W3C Credentials CG (Public List) <public-credentials@w3.org<mailto:public-credentials@w3.org>>; public-vc-edu@w3.org<mailto:public-vc-edu@w3.org> <public-vc-edu@w3.org<mailto:public-vc-edu@w3.org>>
Subject: Re: VC Evidence Discussion

Orie, thanks for the clarification and the useful relatedLink-related links. It does seem to my uninformed eye like a sensible, flexible, minimally wheel-reinventy approach. My reading of the current VC 1.1 spec is also that this doesn't cleanly fit the intention of 'evidence'.

From your earlier reply, it sounds like you see hashlinks as unnecessary, which I thought was interesting. I can certainly see some appeal in avoiding them. For this to work, my understanding is that all linked docs must be either 1. already verifiable, e.g. due to signature (VC) or some other property such as being anchored to a block chain, or 2. hosted securely under control of a party that is ok to change it- perhaps hosted on the issuer's website. I might've imagined that this could require more block-chain and/or hosting expense/complexity than just using hash-links, but perhaps that's not the case. Any thoughts?

Thanks again. Will keep an eye out for that next version of the spec.
Morgan

On Fri, 8 Apr 2022 at 23:25, Orie Steele <orie@transmute.industries<mailto:orie@transmute.industries>> wrote:
We chose to use `relatedLink` because it did not have the `evidence` semantics, and we didn't want linked documents to get automatically downloaded as part of "validation"...

Here are some "related links" from schema.org<http://schema.org>:

https://github.com/schemaorg/schemaorg/issues/1959

https://github.com/schemaorg/schemaorg/issues/1152


> Would you mind elaborating on what you mean by "where you would want to include a reference and sign over a reference instead of a value."?

Sure, when you mint an NFT it has a URI that points to references... that could be very large... Why not just put all that data directly into the smart contract?

A user wouldn't need to read from anything other than the blockchain then...

The answer is the similar for evidence:

1. You might want to change that data behind the URI without breaking the signature
2.  You might want the signature to break if the data behind it changes
3. You might want to add new data behind the URI after the credential was issued
4. The data behind the URI might be several orders of magnitude larger than the credential (like a large ML model / or training set).


OS

On Fri, Apr 8, 2022 at 1:41 AM Morgan Hedges <morgan.hedges@gosource.com.au<mailto:morgan.hedges@gosource.com.au>> wrote:
My apologies.

When I said "relatedDocument", I actually meant "relatedLink". This bit:
"relatedLink": [
    {
      "type": [
        "LinkRole"
      ],
      "target": "did:example:789",
      "linkRelationship": "commercialInvoiceLink"
    },
    {
      "type": [
        "LinkRole"
      ],
      "target": "https://www.example.com/template/123",
      "linkRelationship": "millTestReportLink"
    }
  ],

Looks to me like a fairly general approach?

Morga


On Fri, 8 Apr 2022 at 16:25, Morgan Hedges
<morgan.hedges@gosource.com.au<mailto:morgan.hedges@gosource.com.au>> wrote:
>
> Hi Orie,
>
> I've just noticed the "relatedDocument" field used here: https://w3c-ccg.github.io/traceability-vocab/#BillOfLadingCertificate. Not sure how I've missed this before, but is that the general approach you've got in mind? Would you mind elaborating on what you mean by "where you would want to include a reference and sign over a reference instead of a value."?
>
> Apologies if I'm a little oblivious.
>
> Morgan
>
> On Fri, 8 Apr 2022 at 09:18, Orie Steele <orie@transmute.industries<mailto:orie@transmute.industries>> wrote:
>>
>> We've also been discussing evidence and it's usage in supply chain use cases...
>>
>> I remain hopeful that it will be better tested in the next version of the spec.
>>
>> It needs some serious interoperability tests to support it better, but there are many cars where you would want to include a reference and sign over a reference instead of a value...
>>
>> I don't think adding hash links or other non standard uri formats is a path towards better adoption or interop... But normal URIs seem reasonable... Maybe even DID URLs.
>>
>> Regards,
>>
>> OS
>>
>>
>> On Thu, Apr 7, 2022, 2:24 PM Steve Capell <steve.capell@gmail.com<mailto:steve.capell@gmail.com>> wrote:
>>>
>>> Agree with Michael about clear separation. And with Phillip about maintaining integrity of linked data using hashlinks.  The ability to discover a graph of linked credentials is core to many of our use cases
>>>
>>> But what im less sure about is where to put the linked credential list
>>> - in the Extensibility mode as the VC specification seems to hint?
>>> - in the Evidence model as Kerri suggests  ?
>>> - somewhere in the VC specific claims structure(not keen on this one)?
>>>
>>>  and, wherever the linked credential list goes, what is its structure?
>>> - a simple list of hashlinks? - verifier would have to follow all to find the one they want
>>> - an array of type / hashlinks pairs ? If so, how to consistently represent the type of the linked credential?
>>>
>>> If the group has reached some consensus on the best way to represent linked credentials that would allow verifiers to construct trust graphs - I’d be very keen to hear about it
>>>
>>> Many thanks - and my apologies Kerri if this question is misaligned with your question ..
>>>
>>> Kind regards
>>>
>>> Steven Capell
>>> Mob: 0410 437854
>>>
>>> On 8 Apr 2022, at 4:47 am, Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>> wrote:
>>>
>>> 
>>>
>>> As a general pattern, consider a clear separation of the “thing” from the ownership rights and assignment of those rights to another entity (e.g. person or organization).
>>>
>>>
>>>
>>> A VC is an obvious representation of the thing whether it be an educational achievement, an NFE in an NFT, or house (in the case of homeownership). Use a second VC to represent the ownership rights and the assignment of those rights to an actual person or organization (a verifiable capability authorization is useful for the latter).
>>>
>>>
>>>
>>> …more or less applying the concepts of traditional database normalization to the world of VCs.
>>>
>>>
>>>
>>> Michael
>>>
>>>
>>>
>>> From: Kerri Lemoie <klemoie@concentricsky.com<mailto:klemoie@concentricsky.com>>
>>> Sent: Thursday, April 7, 2022 11:04 AM
>>> To: W3C Credentials CG (Public List) <public-credentials@w3.org<mailto:public-credentials@w3.org>>
>>> Cc: public-vc-edu@w3.org<mailto:public-vc-edu@w3.org>
>>> Subject: VC Evidence Discussion
>>>
>>>
>>>
>>> Hello all,
>>>
>>>
>>>
>>> I’m seeking some input on VC evidence. This is a topic relevant for VC-EDU because education data specifications like Open Badges and CLR may contain an evidence property to support the achievement. This evidence could be a test score, a link to an image, video, and/or web page, etc. that demonstrates competency or participation. These specs are working towards aligning with VCs and it was originally thought that this type of evidence would be included as part of the credentialSubject if it existed.
>>>
>>>
>>>
>>> This would look something like this:
>>>
>>>
>>>
>>> https://json.link/21SpTf0rC4

>>>
>>>
>>>
>>> But since VCs already have an evidence property that allows for an array of evidence, it seems to make sense to use that property instead of using a separate property like the one demonstrated above. The rationalization is that VC evidence could be an array that supports what is needed for a credentialSubject to offer to support the verifiability of a VC such as a student id or it could also support the achievement that is being claimed as discussed above. This would look more like:
>>>
>>>
>>>
>>> https://json.link/0gqe5D1U4K

>>>
>>>
>>>
>>> Can you share your thoughts on this second approach? Do you think the VC.evidence support the achievement evidence too?
>>>
>>>
>>>
>>> Thanks!
>>>
>>>
>>>
>>> Kerri
>>>
>>>
>>>
>>>
>>>
>>>
>>> --------
>>>
>>> Kerri Lemoie, PhD
>>> Director, Digital Credentials Research & Innovation
>>>
>>> badgr.com<http://badgr.com> | concentricsky.com<http://concentricsky.com>
>>> she/her/hers
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>

--


---
The content of this email and attachments are considered
confidential. If you are not the intended recipient, please delete the
email and any copies, and notify the sender immediately.  The information
in this email must only be used, reproduced, copied, or disclosed for the
purposes for which it was supplied.


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


---
The content of this email and attachments are considered confidential. If you are not the intended recipient, please delete the email and any copies, and notify the sender immediately.  The information in this email must only be used, reproduced, copied, or disclosed for the purposes for which it was supplied.