Comments (13)
@msporny here are some more concrete clarifications that I think are the minimum necessary.
Within the section 4.9, state that "An externally secured verifiable credential is not considered a verifiable credential graph. In general, a URL is only considered a verifiable graph when dereferencing the value results in a conformant document according to this data model.".
Within the definition of Presentations, in the verifiableCredential
property, state that "The values of the array MUST NOT be a verifiable credential secured with an external proof.".
from vc-data-model.
@andresuribe87 Can you please be more specific about the sort of "clarification" you're seeking? While everything @iherman says above is accurate, I'm not sure it helps readers.
IOW, we're re-explaining concepts that other specifications explain (like RDF Concepts), or the details are not pertinent to the understanding of implementing VCs. I don't know if you're requesting a few sentences of clarification, and if so, what specifically?
Or you're requesting the depth of explanation @iherman provided to you, which I don't agree is helpful to put in the specification for at least two reasons: 1) those concepts are covered in other specifications; duplicating content is generally frowned upon, and 2) it's not clear how these clarifications impact anyone using or implementing the system?
from vc-data-model.
from vc-data-model.
Seems like making it clear that IRI is included in the range of verifiableCredential
would be all that is needed.
from vc-data-model.
The issue was discussed in a meeting on 2023-12-06
- no resolutions were taken
View the transcript
2.5. Clarify section on verifiable credential graph (issue vc-data-model#1365)
See github issue vc-data-model#1365.
Manu Sporny: (but not support for ignoring the fact that it's not clear to readers that vc-jose-cose is THE specification that outlines how to use SD-JWT with VCDM).
Brent Zundel: andres, is this before or post-CR?
Andres Uribe: I think this should be before CR.
Brent Zundel: Who's willing to be assigned?
Manu Sporny: I am willing to be assigned.
from vc-data-model.
@andresuribe87 wrote:
@msporny here are some more concrete clarifications that I think are the minimum necessary.
Great, thank you for the concrete suggestions, very helpful.
I'm going to get super pedantic here because it'll affect the language that's written. To be clear, I want to write some variation of the language you suggested as long as it's accurate:
Within the section 4.9, state that "An externally secured verifiable credential is not considered a verifiable credential graph.
While an externally secured VC couldn't be directly considered to be a separate graph (in most cases), it could be expressed in a separate graph, which is what PR #1379 does.
There is probably also some language that we could create where one could pre/post-process it and /interpret/ it as a verifiable credential graph... but that would just add complexity for the sake of academic purity. I'm not sure that language would benefit the vast majority of VC authors.
In general, a URL is only considered a verifiable graph when dereferencing the value results in a conformant document according to this data model.".
This sounds true on the surface... I'm trying to think about how this might be mis-interpreted. Developers might think that they can start stuffing URLs in the verifiableCredential
property, which they can't (and doing so wouldn't be very useful w/o cryptographic digest information on the contents).
Within the definition of Presentations, in the
verifiableCredential
property, state that "The values of the array MUST NOT be a verifiable credential secured with an external proof.".
This is true, but then people might think they can't do what's in PR #1379.
I guess I'm trying to figure out if PR #1379 changes any of your suggestions? I think what you're trying to say is "ban the use of pure strings and URLs in the verifiableCredential
array so that people don't continue to keep getting confused about it"?
from vc-data-model.
#1379 does not change my suggestions. It helps provide clarify, but I don't think it's enough.
I think what you're trying to say is "ban the use of pure strings and URLs in the verifiableCredential array so that people don't continue to keep getting confused about it"?
Yes. That's it. I want to provide clarity to implementers on what is and what isn't allowed as a value of the verifiableCredential
property.
from vc-data-model.
Ok, I can change #1379 to include that language. Something to the effect of: "For the avoidance of doubt, you can't have these values..." or, as @dlongley suggested on the call, "MUST be an object and can't be something else, such as..."...
from vc-data-model.
"MUST be an object; i.e., it can't be any non-object, particularly including..."
from vc-data-model.
The issue was discussed in a meeting on 2023-12-13
- no resolutions were taken
View the transcript
2.12. Clarify section on verifiable credential graph (issue vc-data-model#1365)
See github issue vc-data-model#1365.
Brent Zundel: clarify section of verifiable credential graph.
… what needs to change to address this?
Manu Sporny: there is a clear concern, which i think I can address.
… for the avoidance of doubt, the following values are not allowed in a verifiableCredential
.
… I list raw text strings, and URLs.
… it has to be an object of some kind that creates that graph structure.
… and I won't make it exhaustive... its strange to point out, what you cannot put in the field.
Dave Longley: "MUST be an object and can't be something else, such as...".
Andres Uribe: works for me, thanks manu!
Brent Zundel: do you want to mix that into 1379?
Manu Sporny: seems to make sense to put it in 1379.
See github pull request vc-data-model#1379.
Brent Zundel: then it will address that issue as well.
… not hearing anyone opposed to this path.
from vc-data-model.
PR #1390 has been raised to address this issue. This issue will be closed when PR #1390 has been merged.
from vc-data-model.
The issue was discussed in a meeting on 2023-12-20
- no resolutions were taken
View the transcript
4.2. Clarify section on verifiable credential graph (issue vc-data-model#1365)
See github issue vc-data-model#1365.
Brent Zundel: 1365 Clarify section on VC graph. Has PR 1390. Status: wide array of approvals, some ed. Most likely to be merged soon. Then will close.
from vc-data-model.
PR #1390 has been merged, closing.
from vc-data-model.
Related Issues (20)
- Inconsistency between spec and schema HOT 2
- Unify cryptographic hash expression formats HOT 4
- Could not define "name" and "description" as attributes of my type HOT 13
- Comments/Suggestions on Privacy Considerations HOT 7
- SD-JWT fields in the v2 context should use `"@type": "@json"` HOT 4
- Ensure reserved terms are in v2 context HOT 2
- Add Security Considerations related to advances in Artificial Intelligence HOT 4
- consider registering `application/vc-ld` and `application/vp-ld` HOT 20
- Imprecise definition of what should be secured in a VP HOT 4
- Re-evaluate support for `@vocab` in base VCDM v2 context HOT 10
- Pin down the input type of verification algorithms HOT 6
- Verification algorithm drops an input map on the floor HOT 4
- Do VCs support transferrability? HOT 2
- Enable GitHub Discussions HOT 5
- Enhance Context Validation HOT 3
- Publish undefined-terms context URI HOT 6
- Respec's VC plugin still does not work HOT 13
- Data URLs showed in the examples are incorrect HOT 1
- Clarification on the Role of Verifiers in Preventing Replay Attacks HOT 3
- Rename VC Specifications Registry to VC Extensions
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vc-data-model.