search

w3c / vc-data-model

W3C Verifiable Credentials v2.0 Specification
https://w3c.github.io/vc-data-model/
Other
300 stars 109 forks source link

Reference or attach generic (not-credential) data in credential #136

Closed Drabiv closed 5 years ago

Drabiv commented 6 years ago

This issue is a part of general "Reference and Attach data in credential" issue #126

There should be a standard way to reference or attach any data (image, video, html page, archive folder etc) in credential. Related issues: #97

For example, credential issuer wants to reference or attach a visual representation of credential (what user saw when they signed the credential) into credential.

Proposed solution:

Presentation located externally of credential (not attached into crdential)

"reference": [ {
      "id": "14cb57e2-2862-402e-8dd7-f2123a464456 //This is a reference to human readable presentation of this credential",
      "type": [ "Image" ],
      "purpose": [ "Presentation" ],
      "hash": "8fe784bfeaf12ddb27ffcb2e515162af9218e95d5ef430bf13",
      "location": [ "http://example.com/example.img" ]
    }]

Presentation located internally in credential (serialized and inserted into "attachment" property)

"reference": [ {
      "id": "14cb57e2-2862-402e-8dd7-f2123a464456 //reference to human readable presentation of this credential",
      "type": [ "Image" ],
      "purpose": [ "Presentation" ],
      "hash": "8fe784bfeaf12ddb27ffcb2e515162af9218e95d5ef430bf13",
      "location": [ "$.attachment[:].id=ff227bae-dacf-4ef0-94be-b2550ab2ee0q" ]
    },
 "attachment": [
    {
      "type": [ "Presentation" ],
       "content": {
           "id": "https://dmv.example.gov/presentation/f2aeec97-fc0d-42bf-8ca7-0548192d4231",
           "image": {”[content of image in base64]”}
      }
    }
msporny commented 6 years ago

There should be a standard way to reference or attach any data (image, video, html page, archive folder etc) in credential. Related issues: #97

I'm concerned that this is an overgeneralized feature request. JSON-LD's data model already allows us to annotate the credentials with almost arbitrary data. The Verifiable Credentials specification is not solely about image-based credentials. If a credential requires an image-based version, it is up to that market vertical to define the format.

I suggest we do not modify the spec to define the exact format for "attachments" as the problem space is huge.

For example, credential issuer wants to reference or attach a visual representation of credential (what user saw when they signed the credential) into credential.

There is an "evidence" property that is defined in the spec for this.

I propose that we close this issue with no changes to the specification.

Drabiv commented 6 years ago

I think that it will be a standard requirement to have presentation of the credential tamper proofed and referenced from JSON verifiable credential (e.g. passport, tickets, driving license atc). Also, it will common requirement to have other data (not presentation) referenced and tamper proofed. Hence IMO it would be beneficial for community and for adoption of the spec to have it as a part of spec.

stonematt commented 6 years ago

It's only a standard requirement for verticals that consider themselves as "high stakes" This spec must also support claims that are more informal. If we decide to add a more spec element of representations along these lines, it cannot be required. Given the variety of digital representations that may exist or be invented, this feels a little tricky. In the "open world" approach, we have to keep it very lightweight.

-stone

===== Matt Stone 501-291-1599

On Thu, Mar 29, 2018 at 12:01 AM, Bohdan Andriyiv notifications@github.com wrote:

I think that it will be a standard requirement to have presentation of the credential tamper proofed and referenced from JSON verifiable credential (e.g. passport, tickets, driving license atc). Also, it will common requirement to have other data (not presentation) referenced and tamper proofed. Hence IMO it would be beneficial for community and for adoption of the spec to have it as a part of spec.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_vc-2Ddata-2Dmodel_issues_136-23issuecomment-2D377130906&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=KheINWPzU3x8Jj96NXLwS0k5Y5jGbk-Gi1U5Cdx5914&m=Ge3DXCQO0NFhqRxD_1TTODsWCbichU2wxtuf812zD5U&s=8R90T-mITgE1NQs5zIE7Ok9hUvd9an057tXnRZ3CVq0&e=, or mute the thread https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ACsNbr4N52CBk0hM8ghbfPVbeCfpWaNuks5tjHi0gaJpZM4SzRz2&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=KheINWPzU3x8Jj96NXLwS0k5Y5jGbk-Gi1U5Cdx5914&m=Ge3DXCQO0NFhqRxD_1TTODsWCbichU2wxtuf812zD5U&s=94-8D-vu_mPrRJNWkMcx4AcDZHMJ2yUMegeLZxI5sck&e= .

Drabiv commented 6 years ago

Sure, presentation should be optional, just as "evidence" and "termsOfUse".

Given the variety of digital representations that may exist or be invented, this feels a little tricky.

We can just hash whatever was used for presentation (svg, png, jpg, pdf) or even html pages (by downloading and archiving them into one file). Then we can reference presentation using this hash.

"reference": [ {
      "id": "8fe784bfeaf12ddb27ffcb2e515162af9218e95d5ef430bf13" //reference to human readable presentation of this credential,
      "type": [ "Image" ],
      "purpose": [ "Presentation" ],
      "hash": "8fe784bfeaf12ddb27ffcb2e515162af9218e95d5ef430bf13"
    }
msporny commented 6 years ago

We can just hash whatever was used for presentation (svg, png, jpg, pdf) or even html pages (by downloading and archiving them into one file). Then we can reference presentation using this hash.

This is not the way that many of our customers are going... they're trying to get rid of PDFs, images, and anything that requires a human to look at a document in order to make a decision.

To be clear, I'm not saying what you're outlining is not important, it is... but it's not up to the Working Group to define the standard way that images are referenced/hashed. We provide extensibility points and market verticals are free to use them as they see fit.

Drabiv commented 6 years ago

This is not the way that many of our customers are going... they're trying to get rid of PDFs, images, and anything that requires a human to look at a document in order to make a decision.

This is interesting. I see that this is easier in development. But how can they prove later that user signed what he saw... In other words how they ensure that they adhere to the WYSIWYS principle (What You See Is What You Sign - https://en.wikipedia.org/wiki/WYSIWYS)

dlongley commented 6 years ago

I think it would be better to start with a threat model and some use cases before we even attempted to tackle this problem.

That being said, simply capturing images is no guarantee that they were seen by the signer. Furthermore, not everyone can see and we should take that into consideration in any design that begins to hint at creating Web scale systems where sight could become a requirement for participation.

Capturing HTML also does not mean you capture what was rendered. HTML can be rendered differently on different systems. In short, recreating the exact experience that someone had when they signed is quite far from trivial. Even approximations may end up being more harmful than helpful when considering the complexity required to implement such a system.

I don't think that there's a general way to "capture what was seen". It can vary widely by the system used and user who used it. I think it's fine to include evidence, which may be, for example, images, but I don't think it's sensible today to attempt to capture the environment and user information required to properly replicate the experience in verification software that must check it. Nevermind the privacy considerations. I expect it to continue to be largely a matter of law (i.e. to be decided by judge or jury) should there be a dispute over what was signed at a high level of detail.

As stated in another issue, I do think we can capture intent -- as in, why a signature was placed on some data (separate from the data itself to help mitigate spoofing under some scenarios). But I'm wary of us saying we can easily do WYSIWYS -- whilst in actuality we would likely have contributed to more security theater and its unintended consequences.

Drabiv commented 6 years ago

I think in practise it is possible to prove beyond reasonable doubt, that user signed what he saw. This can be achieved by using 3rd party - "credential presentation rendering services", "presentation rendering applications".

As example, let's say gym wants to issue membership card to its member. Workflow will look like this:

This architecture is based on a premise that ecosystem will coalesce around one or several "credential presentation rendering service/applications", which can also work as a trusted services/applications for signing credentials. I think it will be a convention to review and sign credentials on trusted applications/services only.

agropper commented 6 years ago

This issue is core to the HIE of One reference implementation of a self-sovereign technology stack. The use-case we implement is a physician with a DID writing a prescription for a controlled substance. The verification rules are as clear as they get because they’re from the Drug Enforcement Agency (DEA).

HIE of One has

We have implemented most of the elements being discussed but are a ways from implementing the standards - help is welcome. The original white paper was posted to RWOT a long time ago. The current version of the white paper is at https://drive.google.com/file/d/0B_Rve6d1gHMWNmtueU5mTm9wVEk/view The code is at https://github.com/shihjay2/ but it’s somewhat disorganized between a number of related repos.

Is this the use-case we’re looking for?

Adrian

On Fri, Mar 30, 2018 at 1:08 PM Bohdan Andriyiv notifications@github.com wrote:

I think in practise it is possible to prove beyond reasonable doubt, that user signed what he saw. This can be achieved by using 3rd party - "credential presentation rendering services", "presentation rendering applications".

As example, let's say gym wants to issue membership card to its member. Workflow will look like this:

  • Issuer (gym) creates credential (VC JSON), and human readable presentation of it (HTML page)
  • Issuer calculates hash of the presentation and adds it into credential (JSON), and also adds pointer to the location of this presentation (or attaches presentation in serialized form into JSON itself)
  • Issuer signs credential (JSON with hash of presentation) and sends it to the member for him to counter sign it
  • Member does not trust the gym - so he goes to his favourite "presentation rendering service/application" to check what his gym is asking him to sign
  • If member is satisfied with the content of presentation he signs the credential
  • Now if dispute arise, Gym has the proof that user saw what he signed (to be more presize - "must have seen the presentation", or even more presize - "it was users responsibility to check credential's presentation on agreed upon presentation rendering service/application").

This architecture is based on a premise that ecosystem will coalesce around one or several "credential presentation rendering service/applications", which can also work as a trusted services/applications for signing credentials. I think it will be a convention to review and sign credentials on trusted applications/services only.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/136#issuecomment-377572361, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIeYYr55QxEvBprF7LcSygbj2gtoTnnks5tjmaRgaJpZM4SzRz2 .

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: https://patientprivacyrights.org/donate-3/

stonematt commented 6 years ago

this seems related to issue #97

Drabiv commented 6 years ago

As an example of how data (in this case HTML document) can be hashed and referenced within VC, see this Validbook Statement – https://drive.google.com/file/d/1UjIZrREO7iJJ00qJQtaLW1ohtBIx3NgN/view?usp=sharing. Drop it into Validbook Statements service (http://futurama1x.validbook.org/statements) to see verifiable credential on JSON layer of VB statement.

In general, verifier should render HTML and calculate its hash within trusted application. Then verifier will have confidence, that what he sees should have been also seen by the signer when the signer signed this HTML document. Provided that signer used equally trustworthy application to render HTML and calculate its hash.

IMO, it makes possible to fulfill WYSIWYS principle (What You See Is What You Sign) while signing Verifiable Credentials and to display VCs in a human-friendly way.

msporny commented 6 years ago

I'm still having a very hard time understanding why the core specification needs to define this, especially because there are multiple different ways to do what is being proposed. We are not dealing with simple use cases above, but rather very complex ones with multiple moving parts where the suggested solutions assume things that don't exist today, such as "trusted HTML renderers" that are capable of generating hashes for HTML pages.

I also assert that HIE of One doesn't need this feature as the evidence property and claim property meet all of the necessary functionality that @agropper mentioned.

If we want WYSIWYS, that is supported via the evidence property. Why doesn't evidence meet your needs, @Drabiv?

Drabiv commented 6 years ago

In Validbook we have a need to reference data from a credential or attach data into a credential. The proposal is to reference data by using its hash. To attach data, the proposal is to serialize it and place into property 'content', that is a child of property 'attachment'.

The referenced or attached data might not be an evidence of some sort, it may be used for other purposes, for example for human-readable presentation or other purposes. Therefore, it will be not correct to use 'evidence' property.

I have proposed how data can be referenced from, attached into a credential here, but I am open to accept other better proposals or to have explanation of how this can be done using current specs.

@msporny you say there are multiple different ways to do what is being proposed. If possible please explain this on a simple example - referencing and attaching image 'image.png' from/in a simple credential. In other words:

burnburn commented 6 years ago

Hi @Drabiv , we'd like to have you join the Working Group so we can more fully consider your suggestions. Please see https://github.com/w3c/vc-data-model/issues/135#issuecomment-397682978 for details.

Drabiv commented 6 years ago

@burnburn I have applied to become IE to join the group. Thank you!

msporny commented 6 years ago

@msporny you say there are multiple different ways to do what is being proposed. If possible please explain this on a simple example - referencing and attaching image 'image.png' from/in a simple credential. In other words:

  • How to securely reference file from a credential?
  • How to securely attach file into credential?

Sure, here's an example of a cryptographically provable link (hash) to an external image:

{
  "@context": [
    "https://w3id.org/credentials/v1",
    "https://validbook.com/contexts/attachments.jsonld"
  ],
  "id": "http://example.com/credentials/4643",
  "type": ["VerifiableCredential"],
  "issuer": "https://example.com/issuers/14",
  "issuanceDate": "2018-02-24T05:28:04Z",
  "attachment": {
    "id": "https://validbook.com/documents/82973493-image.png"
    "proof": {
      "type": "MessageDigest2018"
      "mimeType": "image/png"
      "digestAlgorithm": "sha256"
      "digestValue": "6702fa56a10e1c7a3de72f96e622a40d41d33e794823c8770bedcc165b2f74f0"
      "created": "2018-07-08T17:22:00.640Z"
    }
  },
  "claim": {
    "id": "did:example:abcdef1234567",
    "name": "Jane Doe"
  },
  "proof": { ... }
}

... and here's an example of embedding an image:

{
  "@context": [
    "https://w3id.org/credentials/v1",
    "https://validbook.com/contexts/images.jsonld"
  ],
  "id": "http://example.com/credentials/4643",
  "type": ["VerifiableCredential"],
  "issuer": "https://example.com/issuers/14",
  "issuanceDate": "2018-02-24T05:28:04Z",
  "claim": {
    "id": "did:example:abcdef1234567",
    "image": "data:image/gif;base64,R0lGODlhEAAQAMQAAOR...AAQA"
  },
  "proof": { ... }
}

... both are cryptographically secured either directly or via content hashes. The data model doesn't need to change at all to support either approach.

Do you find these examples convincing, @Drabiv?

stonematt commented 6 years ago

related to issue #135

Drabiv commented 6 years ago

@msporny if I understood correctly, you propose to define reference (attachment/image/file) property in a Validbook specific context and then use it freely, as per Validbook requirements?

As long as I can reference/attach data in VCs, I am OK with any approach (and your approach and examples to use Validbook specific context looks simple and good for me - thanks!), but ...

General comment - I think reference/attachment is very common and basic functionality, hence it should be made available in the core of VC standard in a very obvious and straightforward way. Especially, if you agree with theoretical understanding that VCs should be foremost understood (looked at) as nodes in a graph of VCs. When you receive a VC, it should have references to other VCs, to enable you (provided you have proper permissions) to traverse graph of VCs, that make possible to understand/analyze/verify the VC in question. Isolated credentials, that are not part of the graph will not be trusted. When we look at credentials in this way (as nodes in a graph of VCs) we can clearly see that there should be a simple, well described standard way to securely reference credentials.

@msporny Just to be sure, with approach provided by you - can I use reference/attachment property multiple times in VC? Can I use these properties inside and outside of "claim" property?
For example, if I I have a Diploma Supplement and I want to reference from it a few dozens of certificates, will I be able to do it with this approach?

The full list of main use cases that I want to satisfy (same as in #136 (comment) )

dlongley commented 6 years ago

@Drabiv,

When we look at credentials in this way (as nodes in a graph of VCs) we can clearly see that there should be a simple, well described standard way to securely reference credentials.

This is what the data model itself already does, but it may need further explaining. Manu and I discussed adding simple tables to the examples in the spec that offer another way to explain the meaning of the JSON.

The VC data model is a graph data model -- where, if you're using JSON/JSON-LD, the JSON keys are links (or edges) in the graph. The link names describe the type of relationship and explain how or why information is connected. Calling it "link" or "reference", therefore is an anti-pattern, because it fails to do just that. All it does it connect the data, it does not describe the relationship. This is why "reference" is a bad name. That doesn't mean that we don't have the feature to link information and ensure it is all cryptographically bound. We have exactly that. What should be done, however, is that the specific type of relationship should be defined by the link type (this speaks to ontology/vocabulary) and its name should also reflect it.

So, for example, these terse sentences are one representation of a graph:

<did:example:123> <name> "Bohdan" .
<did:example:123> <knows> <did:example:456> .
<did:example:456> <name> "Dave" .

They can be represented in JSON like this:

{
  "id": "did:example:123",
  "name": "Bohdan",
  "knows": {
    "id": "did:example:456",
    "name": "Dave"
  }
}

This is a graph where the node identified by "did:example:123" has a link of type "name" that links to a literal node with value of "Bohdan". It also has a link of type "knows" that links to a node identified by "did:example:456". That node itself has a link of type "name" to the literal node with value of "Dave".

You can see how the following is much less useful or less semantically rich; you are left to guess the meaning of the relationships because they aren't explicit in the data itself:

{
  "id": "did:example:123",
  "reference": "Bohdan",
  "reference": {
    "id": "did:example:456",
    "reference": "Dave"
  }
}

And you can see how this following alternative approach is much more verbose:

{
  "id": "did:example:123",
  "reference": {
    "referenceType": "name",
    "referenceValue": "Bohdan"
  },
  "reference": {
    "id": "did:example:456",
    "referenceType": "knows",
    "reference": {
      "referenceType": "name",
      "referenceValue": "Dave"
    }
  }
}

The current design lets you carry more information with less syntax, has a general pattern to follow that uses an existing W3C Recommendation (JSON-LD), and has a number of other advantages we don't get into here.

So, hopefully this better explains why I recommend against using things like "reference" or "link". The design is such that the link (represented as a JSON key here) should define the type of relationship that connects two nodes in the graph and have an appropriate name hinting as to that meaning. If you want a credential to serve as evidence for another claim, use the link term "evidence" to connect the two. If you want something else, use another term we've minted in the core vocabulary or create an extension to specifically represent that type of relationship with a more semantically rich name.

The design is also such that cryptographic proof mechanisms will cover any properly defined extensions. There was some discussion on the most recent call about adding message digests for content integrity for externally linked documents -- and that may be one of the pieces you're looking for here that we'd potentially put into the core spec.

gkellogg commented 6 years ago

Maybe examples could use a graphical layout. Ivan suggested this for all examples in the JSON-LD spec. I was going to try to automate this, along with Turtle and tabular representations.

Drabiv commented 6 years ago

@dlongley thanks for clarification. Now, I see where you are coming from and what you mean by anti-pattern. I agree, that when you are trying to describe/name relationship between something, to call it just 'relationship' is no good. It is not a description. It is just a statement that there is a relationship - which is not what you are trying to do.

I am coming from another perspective. I have a bunch of real-world documents (contracts, certificates, statements of incorporation, court decisions and even specifications etc). These real-world documents have something commonly called "references" - pointers from a part of document to an external documents or to internal parts of the document (usually to appendixes that contain data, but may point to any part of the document).

What I am trying to do is to re-create these real-world-like references.

In usual documents the nature of a relationship between text that has reference and referenced document is often not clear. It is usually inferred from text, although sometimes explanation is given explicitly (e.g. "example", "illustration", "proof", "identification"). Other words that can be used to describe reference - "show, present, argue, suggest, report, address, identify, describe, analyse, note, demonstrate, criticise, compare, observe".

Now, authors of real-world documents do not usually care to describe precisely the nature of a reference link. Sometimes it is too obvious to describe, or too elusive to describe, or it has a few meanings (for example, an image can be an example, an illustration, a proof of something; all in the same time), or the meaning of the reference depends on the reader of the document.

Also, in my case, it is more important to say there is a relationship, than to describe it. Although description is often also important - that's why I proposed to use property "purpose" as a child property of "reference".

Taking into account these 2 perspectives together, I would like to ask you and @msporny and all VC community to understand them together and explain how to agree them, if that is possible.

I am ok to remove property "reference" and instead use one of values from "purpose" property (for example, "evidence", "illustration", "proof", "description") as the property itself, either from the core of VC specs or by creating it in an extension.

But then what to do when:

One solution that comes to my mind (that will IMO resolve the confusion between @dlongley's understing of "reference" and my understanding of "reference") is to rename proposed property to "related" or "relatedData".

So for example, if I want to attach human readable presentation of VC into VC itself I would be able to do it like this: 

"relatedData": [ {
      "id": "14cb57e2-2862-402e-8dd7-f2123a464456 //This is a reference to human readable presentation of this credential",
      "purpose": [ "HumanRedablePresentation", "Illustration"],
      "image": "data:image/gif;base64,R0lGODlhEAAQAMQAAOR...AAQA"
    }]

The same if I had a contract and I wanted to attach Identification documents (issued in VCs spec). in other words attach VC into VC. 

"relatedData": [ {
      "id": "14cb57e2-2862-402e-8dd7-f2123a464456 //This is a reference to human readable presentation of this credential",
      "purpose": [ "Identification"],
      "content":
       ...
       [Driver Licenses of contractual parties]
       ...
    }]

Another way to put this question is – "How to reference/attach data from/in VC with or without describing the relationship between VC and referenced/attached data?"

Another way to explore this issue is to answer this question - "Is it possible to put "VC spec" into VC spec?" If I want to create VC compliant template to put W3C specs in them, so that it can be signed by W3C staff when it becomes a recognized standard. Can I do this? Signed specification is a credential, isn't it? Can we have something like "W3C certificate of official specification"?

So, how to put VC spec into VC spec?

msporny commented 6 years ago

One solution that comes to my mind (that will IMO resolve the confusion between @dlongley's understing of "reference" and my understanding of "reference") is to rename proposed property to "related" or "relatedData".

There is a well-established way to do this already:

https://www.w3.org/TR/rdf-schema/#ch_seealso

If we wanted to be more specific, we could reuse:

https://schema.org/citation

At this point, we need to make a decision:

  1. Add rdfs:seeAlso or schema:citation to the core VC Data Model JSON-LD Context and add a normative example to the specification, OR
  2. Add a non-normative section on referencing external documents and include examples for seeAlso and citation, making it clear that if a more specific mechanism exists to reference a document (such as evidence), it should be preferred to more generic terms like seeAlso and citation.

I think either approach addresses @Drabiv's request, but I would prefer that the group take approach 2 as this decision has a high liklihood of being the wrong one if we make it normative. Tthere are many ways to reference other resources on the Web/Internet, as @Drabiv noted in his comments, and suggesting that there is only one or two ways to do it will almost certainly come back to bite us in the future.

@Drabiv what would you prefer? I'd also like to get some other comments in here before putting together a PR to address this issue.

Drabiv commented 6 years ago

@msporny I agree that the 2nd, non-normative option is preferrable.

Saying this, I think usage of "rdfs:seeAlso" adds confusion and another layer of complexity. First, the semantic meaning of "see also" is a bit different, than "reference" or "related data". "See also" sounds like afterthought, something less important. The meaning is different than in straightforward "related data". I know it arguable, but IMO this adds confusion. Second, "rdfs:seeAlso" uses "rdfs:". Which brings questions. What is "rdfs:"? Why we need to use it? This is another layer of complexity.

The above critique is just my reservations towards the usage of "rdfs:seeAlso". It does not prohibit its usage.

My main question towards the usage of "rdfs:seeAlso" is – can it be used with additional properties like "purpose", "hash", "location" to enrich it with meaning (see example below)?

"rdfs:seeAlso": [ {
      "id": "14cb57e2-2862-402e-8dd7-f2123a464456",
      "purpose": [ "HumanRedablePresentation", "Illustration"],
      "hash": "8fe784bfeaf12ddb27ffcb2e515162af9218e95d5ef430bf13",
      "location": [ "http://example.com/example.img" ]
    }]
msporny commented 6 years ago

@msporny I agree that the 2nd, non-normative option is preferrable.

Great, I'll create a PR for that approach, then. Thanks @Drabiv.

My main question towards the usage of "rdfs:seeAlso" is – can it be used with additional properties like "purpose", "hash", "location" to enrich it with meaning (see example below)?

Yes, it can. Also, I suggest you read the RIPs paper wrt. your example:

https://github.com/WebOfTrustInfo/rwot7/blob/master/topics-and-advance-readings/resource-integrity-proofs.md

As far as this comment from you:

I think usage of "rdfs:seeAlso" adds confusion and another layer of complexity.

I think you can now see why we're so hesitant to call out a very specific way of doing this. While you are not familiar with rdfs:seeAlso, there is a very large community of semantic web folks that are and would suggest that to be the most generalized solution (and that we should make it normative). Folks outside of that community, like you, are rightly confused by rdfs, even though it can be thought of as a core library.

Fundamentally, most developers wouldn't have to know. The code would be more like this:

"seeAlso": [ {
      "id": "urn:uuid:14cb57e2-2862-402e-8dd7-f2123a464456",
      "purpose": [ "HumanRedablePresentation", "Illustration"],
      "hash": "8fe784bfeaf12ddb27ffcb2e515162af9218e95d5ef430bf13",
      "location": [ "http://example.com/example.img" ]
    }]

Note that "seeAlso" doesn't have the rdfs prefix on there.

In any case, I'll draw up an example with both because if I don't, one of the communities is probably going to object.

msporny commented 6 years ago

@kimdhamilton and @gannan worked on a paper at RWoT7 called Resource Integrity Proofs that enables this:

https://github.com/WebOfTrustInfo/rwot7/blob/master/draft-documents/resource-integrity-proofs.md

So the general problem is "solved", but there is not spec text, the RIP stuff is a separate document that's not a W3C spec yet, this WG has no charter deliverable for it, and thus all we would be able to do is refer to that document.

I suggest we defer this and put a note about this in an "Implementation Guidance" document. We should refer to the implementation guidance document from the vc-data-model spec.

stonematt commented 6 years ago

Implementation guidance is a document that we need to start as a WG Note. This seems like a good landing place to describe a “one of several” ways to apprach the general problem of citations and/or ancillary content.

On Mon, Oct 22, 2018 at 15:26 Manu Sporny notifications@github.com wrote:

@kimdhamilton https://github.com/kimdhamilton and @gannan https://github.com/gannan worked on a paper at RWoT7 called Resource Integrity Proofs that enables this:

https://github.com/WebOfTrustInfo/rwot7/blob/master/draft-documents/resource-integrity-proofs.md

So the general problem is "solved", but there is not spec text, the RIP stuff is a separate document that's not a W3C spec yet, this WG has no charter deliverable for it, and thus all we would be able to do is refer to that document.

I suggest we defer this and put a note about this in an "Implementation Guidance" document. We should refer to the implementation guidance document from the vc-data-model spec.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/136#issuecomment-431993509, or mute the thread https://github.com/notifications/unsubscribe-auth/ACsNbhIbEV5Y6QUfKRXHXOuKbI6kaljJks5unjfwgaJpZM4SzRz2 .

-- -stone

brentzundel commented 5 years ago

Decision at Barcelona F2F: Create an issue in the implementation guide repo and close

brentzundel commented 5 years ago

@msporny This issue is assigned to you. Are you able to take the work items from Barcelona?

stonematt commented 5 years ago

Moving to https://github.com/w3c/vc-imp-guide/issues/5

closing.

msporny commented 5 years ago

Text was added to the VC Data Model spec that covers this use case: https://w3c.github.io/vc-data-model/#content-integrity-protection

@Drabiv, does this address your concern or would you want more written about referencing external resources?

burnburn commented 5 years ago

@drabiv we plan to close the corresponding implemetation guide issue https://github.com/w3c/vc-imp-guide/issues/5 . Are you okay with us marking this as closed?