-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change on what exactly must be secured in a presentation #1515
Conversation
@@ -4266,9 +4266,10 @@ <h3>Securing Mechanism Specifications</h3> | |||
[=default graph=]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't make a suggestion here, but I believe this should not be a statement about a "property" but about a securing mechanism, and it should be simplified to "The securing mechanism MUST secure all graphs in a [=verifiable credential=] not referred to by the property itself."
Similarly, the above "The property MUST define" seems more like it should say "The securing mechanism MUST define". This list should perhaps be about the requirements for the property and the new securing mechanism.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder whether —
Securing mechanism specifications that create new types of [=embedded proofs=]
MUST specify a [=property=] for securing
— should become the following (which implies further changes to the bullet list, and possibly more) —
Securing mechanism specifications that create new types of [=embedded proofs=]
MUST specify an object for securing both [=verifiable credentials=] and
[=verifiable presentations=].
— (should object
be [=object=]
?) with appropriate bullet adjustments, such as —
The object MUST provide values for all [=properties] used by the [=proof graph=].
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I not against making this change, but that is more complex change than what this PR proposes to do. I would prefer to finalize this PR first and, if needed, do that in a separate PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
B.t.w., @TallTed, the (RDF) "object" term is not used in the core VCDM terminology, only "value".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With dlongley's amendments made by TallTed I support PR #1515
Co-authored-by: Dave Longley <dlongley@digitalbazaar.com>
I have merged the proposal of @dlongley but I am not absolutely sure this is 100% correct. Let us take the hypothetical situation as follows.
Question: does |
We should close this PR without merge, and concentrate on the more comprehensive #1519 instead. |
The discussion has clearly moved to #1519, closing this PR without further action, to avoid misunderstandings. |
This is to answer to the issue raised in #1512
Preview | Diff