Re: VC Evidence Discussion

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> 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> 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> 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> 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>
>>> Sent: Thursday, April 7, 2022 11:04 AM
>>> To: W3C Credentials CG (Public List) <public-credentials@w3.org>
>>> Cc: 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 | 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.

Received on Friday, 8 April 2022 16:05:01 UTC