Add mechanism to embed enveloped VCs in VPs. #1358
Conversation
msporny
requested review from
dlongley,
m00sey,
jandrieu,
iherman,
dmitrizagidulin,
TallTed,
David-Chadwick,
decentralgabe,
selfissued,
OR13,
brentzundel,
awoie,
Sakurann and
seabass-labrax
Co-authored-by: Dave Longley <[email protected]>
Yes, I went back and forth on those alternatives as well. I've seen "enveloping" thrown around in various communities, and have heard others in the VCWG start to use that terminology, so wanted to try that terminology out on this PR. Happy for others to jump in w/ bikeshedding suggestions. We're not changing the concepts, just trying to find a better way to convey them. The real world analogy of an "envelope" and a "watermark" seem to be the closest so far. The JOSE, COSE, ACDC, and Gordian approaches put the data to be secured in an envelope (like putting a letter in an envelope that is sealed w/ an official wax seal). Data Integrity watermarks the data by adding something to the data (like how holograms and UV ink watermarks are used to secure the authenticity of a physical passport or driver's license). Those analogies feel like they pass the "Explain the concept in a sentence or two to the general public." test. |
I'm not a fan of enveloping as a descriptor as it also means obscures or shrouds. I'd prefer "proof envelope" but I'm not going object if this is the preference of the group. |
|
@longpd wrote:
Well, that's exactly what the enveloping proof formats do. :) They take something that looks like this: and turn it into something that looks like this (the envelope): So the data is obscured/shrouded, as you say ^ |
|
This PR made it clear to me that we need to provide more clarity to readers on what is and what is not a verifiable credential graph. Implementers should be able to easily and quickly answer the question "Is X a verifiable credential graph?". I'd like to start by providing some examples, and what I believe the answer is for each.
If we're in agreement with the above, I'd like to suggest that:
I'd be happy to raise both points above as separate issued. It seemed to me that this PR was the correct place, as it is building on top of those missing definitions. Or perhaps this was already discussed elsewhere and I missed it. [1] {
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": ["VerifiableCredential", "ExampleDegreeCredential"],
"issuer": "https://university.example/issuers/565049",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
}
}
}[2] [3] {
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2",
"https://w3id.org/security/suites/ed25519-2020/v1"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/565049",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
}
},
"proof": {
"type": "Ed25519Signature2020",
"created": "2023-11-26T23:04:13Z",
"verificationMethod": "https://university.example/issuers/565049#key-1"
,
"proofPurpose": "assertionMethod",
"proofValue": "zbZuLBB1qkoK3KShFs1USRrhXn6bTmQ2tQhANtYYNM5zntoygX5Q3zJUKZaQpWXzRPd4Cd8iYxq1PobiNXk97SUW"
}
} |
I do not have a strong opinion about the 'envelope' analogy, which may indeed be better than the 'external' one. But I am not really sure what the problem is with 'embedded'. It worked for me at least... |
|
Forgive me if I am very pedantic reflecting on #1358 (comment). A credential (verifiable or not) is a set of statements which is always part of (or is) a graph. (That is true to any RDF structure, not specific to credentials.) That graph may be explicitly "created" (or designated) as a named graph, or it is the so-called default graph. These terms are actually defined in the RDF specification, but were taken over into the terminology of the VCDM by leaving out some aspects that VCDM does not use. With that, some of my comments:
I think that we had this discussion before. The way it was discussed was whether we need two separate types, one for @msporny will remember the details of the discussion. But I do not think we should reopen this issue.
As I said above, that is not correct. The question is whether it is a separate named graph or is part of the single (default) graph. Provided that [2] is an encoded version of something like [1], it is a default graph. (Named graphs appear in the spec with verifiable presentations.)
Per our specification, [3] is actually a collection of two graphs. The credential part, which is the default graph, and the proof graph, which (per definition of the
The normative definition of graphs is in the spec (admittedly, this is a recent change on the document). That said, your comments do raise a very important question that is relevant to this PR. The
In an ideal world, I would agree with you. Yes, the term |
I appreciate the extra detail and thoughtful response @iherman, thanks!
Are you saying that [1] IS a verifiable credential graph? If so, would you say that [1] IS a verifiable credential? I consider it very important to align on examples, because they leave less space for ambiguity. I'm trying to use the terms "credential" and "verifiable credential" in the way that's not ambiguous, with the distinction that we've made in the spec under section 3.
I think I follow your argument, but if that's the case, then why aren't we able to have [2] be an item of a
I've read section 9 now multiple times, and I'm still not able to define what a "verifiable credential graph" is. That section is introducing a concept, but it's not defining it. Could you explain further what it is? Happy to open a separate issue to elaborate on this further.
I would argue that if renaming fixes these sort of bugs, that's exactly what we should do in 2.0 :) [4] {
"vc": {
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "http://university.example/credentials/3732",
"type": [
"VerifiableCredential",
"ExampleDegreeCredential"
],
"issuer": "https://university.example/issuers/565049",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
}
}
},
"iss": "https://university.example/issuers/565049",
"jti": "http://university.example/credentials/3732",
"sub": "did:example:ebfeb1f712ebc6f1c276e12ec21"
} |
My comment was on the question whether it is a graph or not a graph. And I do say that yes, it is a graph. The question you seem to ask is whether it is a verifiable credential or just a plain credential. What I said was that this is a different issue: do we want to make a very clear distinction between these two terms. I.e., should we say that it is a verifiable credential if and only if there is either a […]
If my understanding is correct, your question is why we need the separate property introduced in this PR, i.e., why isn't it enough to use the That extra action must be specified separately if this is really the intention. Technically, the semantics of the new property would have to say explicitly: "you decode the content of the URL and you create a set of RDF statements that you consider as such...". Alternatively, the semantics should clearly say that the literal is to be taken as an opaque entity for the purpose of, say, the signature of a VP (by "opaque", I mean that the signature should simply sign, among other things, the encoded form). And you are right: this may have to be defined with more care than it is now. I will raise a separate comment as part of my formal review. […]
The formal definition is really in the RDF spec, so I am forced to go back to the RDF world. Hopefully, in this case, this helps. And my apologies for the verbosity of my answer. The reason we are talking about named graphs in RDF is because the concept is, basically, to have a graph with its own, distinct identity, i.e., a name which, in the RDF world, is a URL. To use a somewhat different syntax, one could have something like: We have here two, distinct credentials, i.e., credential graphs. If I use the URL What muddles the waters a bit is that, as it is the case for RDF in general, I can also use a blank node instead of a clear URL, which is something like saying "we know there is a distinct identifier but we do not care what it is". (It is an "existential term" in logic). So I could have: where The way the JSON-LD I.e., only blank nodes are used. If there are more than one credentials, then each gets its own blank node, ie, they are all mutually separated. Does this help a bit? And yes, I believe any further clarification should be subject of a separate issue...
As I said: in theory yes, pragmatically probably not. But that is a really separate issue, too, I believe. |
| </dd> | ||
| <dt><var id="defn-envelopedVerifiableCredential">envelopedVerifiableCredential</var></dt> | ||
| <dd> | ||
| The <code>envelopedVerifiableCredential</code> <a>property</a> MAY be present. | ||
| The value MUST be an array of one or more <a>URLs</a> using the `data:` URL | ||
| scheme where each value contains a <a>verifiable credential</a> that | ||
| is secured using an <a>enveloping proof</a>. |
There was a problem hiding this comment.
As the discussion with @andresuribe87 shows: this term may not be properly defined. The question is: what is exactly the semantics and the behavior v.a.v. the encoded verifiable credentials? This may become a question if the enclosing VP has to be signed, for example. I can see two alternatives:
- The idea is that the data URL is "dereferenced" which, in this case, would mean that data part is decoded, and the resulting VC is put into its own VC graph (just like what happens in the case of the
verifiableCredentialterm). - The data URL content is, essentially, opaque; the signature of the VP happens with that term taken verbatim, i.e., as a string. Everything else, i.e., what to do with that credential, falls into the application domain.
I think that to properly specify (1) is problematic, and requires quite a lot of additional specification text. That approach would not really go well with the Linked Data aspect: it looks like having a "plugin" processor put into the JSON-LD processing.
Alternative (2) is clean (although with a caveat, see below), but I am not sure whether it is what the expectation is with that property.
As for the caveat: the usage of a URL, i.e., a data URL, is questionable in the case of alternative (2). See my separate comment on the relevant issue
There was a problem hiding this comment.
Alternative (2) is clean (although with a caveat, see below), but I am not sure whether it is what the expectation is with that property.
Agreed, and I believe it's aligned w/ the expectation.
IMHO, that /is/ a separate graph of information (or rather, should be treated as one) and we can say that in the specification. IOW, it's not presumed that one would take that signed object and merge it into the default graph. There is also an expectation that it contains a conforming document that is secured using the rules for the media type.
There was a problem hiding this comment.
Alternative (2) is clean (although with a caveat, see below), but I am not sure whether it is what the expectation is with that property.
Agreed, and I believe it's aligned w/ the expectation.
👍
IMHO, that /is/ a separate graph of information (or rather, should be treated as one) and we can say that in the specification.
We have to be very cautious then how we formulate that. From a Linked Data perspective and, consequently, from the terminology used in the specification, it is not a separate graph, it is "just" a more-or-less opaque string. The application level, could (should? must?) do additional checks on whether it can be decoded into a graph and whether that graph is conforming to our specification. But that is on a different layer.
Very specifically. If I sign, using RCH or via JWS, a VP that uses this term, that signature applies on the encoded string, i.e., the value of the property and not on the decoded graph. This must be clearly specified in the spec, otherwise we run into problems imho.
IOW, it's not presumed that one would take that signed object and merge it into the default graph. There is also an expectation that it contains a conforming document that is secured using the rules for the media type.
Ok. I think we are aligned. Now comes the simple task of formalizing that succinctly in the document 😀.
There was a problem hiding this comment.
@msporny, you did not react on the exact specification of the term's range, ie, whether we define a new datatype or whether leave it as a URL...
There was a problem hiding this comment.
Now comes the simple task of formalizing that succinctly in the document
The above gives me enough to make an attempt at a PR modification, thank you.
specification of the term's range, ie, whether we define a new datatype or whether leave it as a URL...
Let's leave it as a URL for now, because it is a URL. You are signing over an opaque URL and it's up to the application to interpret that URL, and we'll provide guidance on exactly how applications should interpret that URL (evaluate the URL, it should result in a separate graph that contains a VC that is secured using some recognized securing mechanism). I'll try to be less hand-wavy in the PR contents.
There was a problem hiding this comment.
Ok, let us try to go the simple way and keep it as a URL... Let us see where this goes.
I see what you mean now, agreed.
Perfect, that all makes a ton of sense. Looking forward to clarifying that piece in the spec.
This makes a ton of sense, thanks for taking the time to explain. I've raised #1365
Raised #1366 |
|
@iherman and @andresuribe87 -- it's not clear to me what changes you want to be made to this PR. I have read your discussion, and have philosophical thoughts/input, but none of which I'm confident of applying to this PR. Can you please more clearly state what you'd like changed in this PR before you'd be ok with it being merged? I will follow up in the issues that each of you have created in an attempt to add my thoughts. Requesting re-review from both of you, please provide concrete change suggestions. |
I am not requiring any change. The question is whether the fact of @andresuribe87 not understanding things can be explained by some ambiguities in the text, or whether it can be avoided by some improvements. @andresuribe87, only you can tell us that... |
| @@ -2022,11 +2022,11 @@ <h3>Securing Verifiable Credentials</h3> | |||
| </p> | |||
| <p> | |||
| This specification recognizes two classes of securing mechanisms: those that use | |||
| external proofs and those that use embedded proofs. An | |||
| <dfn class="export">external proof</dfn> is one that wraps an expression of | |||
| enveloping proofs and those that use watermarking proofs. An | |||
There was a problem hiding this comment.
watermarking typically implies some difficulty in removing the mark... this is not true of embedded proofs.
I think the term embedded proofs was better here...
| "type": ["VerifiablePresentation", "ExamplePresentation"], | ||
| "envelopedVerifiableCredential": [ | ||
| "data:application/jwt;base64,QzVjV...RMjUK==", | ||
| "data:application/cwt;base64,ZmlOW...pYzMK=" |
There was a problem hiding this comment.
A CWT can never be a"verifiable credential"... CWTs secure a CBOR map as a payload.
Verifiable Credentials secure a Compact JSON-LD Document as a payload.
| ], | ||
| "id": "urn:uuid:5ec137ea-871e-11ee-a783-ef96a4397a9a", | ||
| "type": ["VerifiablePresentation", "ExamplePresentation"], | ||
| "envelopedVerifiableCredential": [ |
There was a problem hiding this comment.
I take it this is believed to be needed because dynamic RDF Processors struggle with this:
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"id": "urn:uuid:5ec137ea-871e-11ee-a783-ef96a4397a9a",
"type": ["VerifiablePresentation", "ExamplePresentation"],
"verifiableCredential": [
"data:application/jwt;base64,QzVjV...RMjUK==",
"data:application/cwt;base64,ZmlOW...pYzMK="
]
}
<urn:uuid:5ec137ea-871e-11ee-a783-ef96a4397a9a> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiablePresentation> .
<urn:uuid:5ec137ea-871e-11ee-a783-ef96a4397a9a> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/ns/credentials/examples#ExamplePresentation> .
<urn:uuid:5ec137ea-871e-11ee-a783-ef96a4397a9a> <https://www.w3.org/2018/credentials#verifiableCredential> "data:application/cwt;base64,ZmlOW...pYzMK=" .
<urn:uuid:5ec137ea-871e-11ee-a783-ef96a4397a9a> <https://www.w3.org/2018/credentials#verifiableCredential> "data:application/jwt;base64,QzVjV...RMjUK==" .
I don't think these changes are helpful.
There was a problem hiding this comment.
I do not understand the remark "dynamic RDF Processors struggle with this". Actually, I do not even understand what you mean by "dynamic RDF Processor"...
From a pure RDF point of view, there is no struggle. A data URL is a URL, no difference between that one an any other URL.
There was a problem hiding this comment.
If what you mean is that one could use an absolute URL (e.g., a data URL) as a value for the verifiableCredential property, hence there is no need for a new property, that by itself is a correct statement. But I do not think it is what is meant by the original discussion, and it is actually related to the discussion I had with @andresuribe87.
The value of the verifiableCredential is not a URL for a credential. It is the URL for a named graph that contains a credential. I believe the original issue in the WG was to have a property that refers (directly) to an externally secured credential (e.g., JOSE-COSE). These two are not the same.
Looking at your examples
<urn:uuid:5ec137ea-871e-11ee-a783-ef96a4397a9a> <https://www.w3.org/2018/credentials#verifiableCredential> "data:application/cwt;base64,ZmlOW...pYzMK=" .
is actually wrong. The proper representation in nquads would be:
<urn:uuid:5ec137ea-871e-11ee-a783-ef96a4397a9a> <https://www.w3.org/2018/credentials#verifiableCredential> _:b1 .
<data:application/cwt;base64,ZmlOW...pYzMK=> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> _:b1 .
It is questionable whether this is what we want, semantically. The usage of a separate property side-steps this issue, which sounds o.k. to me if this is what the WG wants.
See also my separate discussion on the feature a few days ago and in what follows.
See my comment below: we have to decide whether that feature is really necessary or not.
There was a problem hiding this comment.
@OR13 ,
I just realized that your set of n-quads, i.e.,
<urn:uuid:5ec137ea-871e-11ee-a783-ef96a4397a9a> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiablePresentation> .
<urn:uuid:5ec137ea-871e-11ee-a783-ef96a4397a9a> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/ns/credentials/examples#ExamplePresentation> .
<urn:uuid:5ec137ea-871e-11ee-a783-ef96a4397a9a> <https://www.w3.org/2018/credentials#verifiableCredential> "data:application/cwt;base64,ZmlOW...pYzMK=" .
<urn:uuid:5ec137ea-871e-11ee-a783-ef96a4397a9a> <https://www.w3.org/2018/credentials#verifiableCredential> "data:application/jwt;base64,QzVjV...RMjUK==" .
were generated by the JSON Playground, and you were misled because there is, in my view, a bug somewhere, see #1373.
That being said, there is also a bug in my head, because what I said should be the result, namely:
<urn:uuid:5ec137ea-871e-11ee-a783-ef96a4397a9a> <https://www.w3.org/2018/credentials#verifiableCredential> _:b1 .
<data:application/cwt;base64,ZmlOW...pYzMK=> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> _:b1 .
This is also wrong, insofar as there is no ground for the second triple. From a JSON-LD point of view, I believe the only triple that is generated is
<urn:uuid:5ec137ea-871e-11ee-a783-ef96a4397a9a> <https://www.w3.org/2018/credentials#verifiableCredential> _:b1 .
which makes it even more unsuitable for what we need...
I cc @BigBlueHat and @dlongley here, because I never feel comfortable with JSON-LD...
There was a problem hiding this comment.
@OR13's example doesn't use the approach proposed here and pulls in the examples context with it's "catch-all" vocab...so it doesn't accurately represent the changes proposed here, but rather shows what's broken without these changes.
The context changes that would be made once #1372 is merged would look more like the following--which uses the term proposed here defined as a URL/IRI as expressed in #1372:
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
{"envelopedVerifiableCredential": {"@type": "@id"}}
],
"id": "urn:uuid:5ec137ea-871e-11ee-a783-ef96a4397a9a",
"type": ["VerifiablePresentation", "ExamplePresentation"],
"envelopedVerifiableCredential": [
"data:application/jwt;base64,QzVjV...RMjUK==",
"data:application/cwt;base64,ZmlOW...pYzMK="
]
}Resulting quads look like--which reads correctly to me based on this PR and the vocab changes proposed in #1372:
<urn:uuid:5ec137ea-871e-11ee-a783-ef96a4397a9a> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiablePresentation> .
<urn:uuid:5ec137ea-871e-11ee-a783-ef96a4397a9a> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/ns/credentials/issuer-dependent#ExamplePresentation> .
<urn:uuid:5ec137ea-871e-11ee-a783-ef96a4397a9a> <https://www.w3.org/ns/credentials/issuer-dependent#envelopedVerifiableCredential> <data:application/cwt;base64,ZmlOW...pYzMK=> .
<urn:uuid:5ec137ea-871e-11ee-a783-ef96a4397a9a> <https://www.w3.org/ns/credentials/issuer-dependent#envelopedVerifiableCredential> <data:application/jwt;base64,QzVjV...RMjUK==> .
|
On the call of Nov. 15 the issue of adding a property to VP to represent externally defined proofs came up. This PR is a proposal to handle that issue. With that:
Do you mean that, after all, such extra property is not necessary, or that the proposed approach is not the right one? If the former, make this statement clearly, and we can, if there is an agreement, close this issue and move on. If the latter, what is your alternative.
This goes back to what I asked above. Do you mean that we do not need that feature, or that this feature would be harmful?
I do not understand that remark. I am not taking side on the issue, but I am not an VC application developer, hence I cannot judge whether that extra feature is necessary or not. |
@OR13, I've updated your example to reflect what's proposed here. Hopefully that makes these improvements more obvious. |
|
The issue was discussed in a meeting on 2023-12-05
View the transcript1.5. Add mechanism to embed enveloped VCs in VPs. (pr vc-data-model#1358)See github pull request vc-data-model#1358. Brent Zundel: enveloped VCs. Manu Sporny: originally had a concept to introduce related resource. group said "no" we have two different cases, securing contexts and expressing JWT-protected VCs in VP. mike: This seemed to be changing established terminology for not commensurate benefit. No proportional benefit.
Sebastian Crane: Manu, can you provide a link to the original discussion that brought up the idea of an enveloped VC, which seems like a radical new concept from what we have already. Manu Sporny: it's #1265. It's a long thread. See in particular, this comment.
mike: watermarking doesn't work for me. Brent Zundel: I think I understand the reasoning behind this mechanism, that the way VC property is defined makes is so you can't just shove a JWT in there. Dave Longley: this comes down to the fact that we have two different proof mechanisms. Brent Zundel: I think I tracked most of that.
Dave Longley: JSON-LD is a subset of JSON, so you can put anything in a JSON and so you CAN add that to JSON LD. Brent Zundel: in other properties, we had a type property to say how you handle different variations. Andres Uribe: I propose we separate these into two terms (whatever those are). Dave Longley: so you never were able to put a JWT into that property. That was never conformant. Manu Sporny: if this is a data URL can we just use an ID property to slap type on it?
Manu Sporny: this would be a better design than using relatedResource.
Brent Zundel: if I'm understanding, then we keep Joe Andrieu: For the object in the array, for a JSON-LD credential, would have A property that is the credential and a type. That object isn't directly a VC, it's a new thing that's wrapping around the VC as JSON-LD, not as a new data format. Dave Longley: I think we also need to put the context back onto that object. |
|
Not being at the call, my reaction on the discussion on the 5th of December. My understanding of the minutes is to do something like this: "verifiableCredential" : [
{
… this is a 'traditional' credential, i.e., with an embedded proof
},
{
"id": "data:...."
"type": "EnvelopedVerifiableCredential"
}
]Did we consider the fact that Also, can I put a non-data URL in the "id" field? Per JSON or JSON-LD, I can. What does that mean in terms of proofs? (Per default, the signature through DI only signs the URL string, nothing else.) Maybe all this works, but I just wanted to raise a flag... |
|
Just putting this out there (and this is only an opinion and not a formal objection): unless things fall into place quickly and easily, I wonder whether we should not close this PR and declare the issue as deferred. After all, this is a new feature request that popped up a few weeks ago only; per our own agreements, we have frozen the spec and accepting a new feature request was not supposed to happen in the first place... |
|
The issue was discussed in a meeting on 2023-12-06
View the transcript3.1. Add mechanism to embed externally secured VCs in a VP (issue vc-data-model#1352)See github issue vc-data-model#1352. Brent Zundel: This issue is being addressed by the PR we discussed yesterday. |
|
This PR is marked as pending close. @OR13 has made it clear that no variation of it will be acceptable to him. We have an alternate proposal that I will try to do a PR for related to a discussion during the WG call. If that fails, we will close issue #1352 and note that the WG couldn't come to consensus on embedding externally secured documents in a VP (even though multiple workable proposals were put forward). |
|
Closing, superseded by #1379 |
This PR attempts to address issue #1352 by adding a new feature for embedding "enveloped" Verifiable Credentials in order to support JWT/CWT/Gordian/ACDC-secured VCs in presentations. It also renames the "external proof" securing mechanism class to "enveloping proof" and the "embedded proof" securing mechanism class to "watermarking proof" in order to convey the concept using better analogies.
/cc @m00sey @ChristopherA @SmithSamuelM
Preview | Diff