-
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
Clarify proof section #1106
Clarify proof section #1106
Conversation
Signed-off-by: Brent Zundel <brent.zundel@gmail.com>
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 like securing!
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.
This is clearer than the text that it replaces.
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.
A small tweak. Otherwise, strongly in favor of this 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.
Excellent 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.
Thanks! +1 to @TallTed's suggestion and I have one minor clarifying one of my own.
Methods of securing <a>credentials</a> or <a>presentations</a> that embed a | ||
proof in the data model MUST use the <code>proof</code> <a>property</a>. |
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'm just noting a bit of concern on this item. I think it's a good call for v2.0 as long as future major revisions allow for possibly other fooProof
properties that also secure the data model (in the event that proof
is not flexible enough. I highly doubt that proof
wouldn't be flexible enough, but just thought it worth mentioning before merging this PR. We don't want to block other embedded proofing mechanisms (forever) from existing and being used for VCs.
Normative, multiple reviews, changes requested and made, no objections, merging. |
This PR makes minor normative changes to the proof section.
It renames the section to indicate that the focus is on Securing VCs.
It rewords the introduction to focus on securing rather than proofs.
It clarifies the normative possibilities around the proof property to better reflect the way it is actually used.
fixes #1104
Preview | Diff