Skip to content
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.

Sign up for GitHub

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

Add mechanism to embed enveloped VCs in VPs. #1358

Closed
wants to merge 2 commits into from
Closed

Add mechanism to embed enveloped VCs in VPs. #1358

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
83153e6
Add mechanism to embed enveloped VCs in VPs.
msporny Nov 19, 2023
3ef9512
Fix grammar on watermarking proof definition.
msporny Nov 20, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 38 additions & 10 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

<dfn class="export">enveloping proof</dfn> is one that wraps an expression of
this data model, such as via a JSON Web Token, which is elaborated on in the
<em>Securing Verifiable Credentials using JOSE and COSE</em> [[VC-JOSE-COSE]] specification.
An <dfn class="export">embedded proof</dfn> is a mechanism where the proof is
A <dfn class="export">watermarking proof</dfn> is a mechanism where the proof is
included in the data model, such as a Data Integrity Proof, which is elaborated
on in <em>Verifiable Credential Data Integrity</em> [[VC-DATA-INTEGRITY]].
</p>
Expand All @@ -2045,7 +2045,7 @@ <h3>Securing Verifiable Credentials</h3>
</p>
<p>
Methods of securing <a>verifiable credentials</a> or <a>verifiable
presentations</a> that use an external proof MAY use the <code>proof</code>
presentations</a> that use an enveloping proof MAY use the <code>proof</code>
<a>property</a>.
</p>
<dl>
Expand All @@ -2056,7 +2056,7 @@ <h3>Securing Verifiable Credentials</h3>
the authorship of a <a>verifiable credential</a> or a <a>verifiable
presentation</a>. Each proof is a separate <a>named graph</a>
(referred to as a <dfn class="export">proof graph</dfn>) containing a single
proof. The specific method used for an <a>embedded proof</a> MUST be identified
proof. The specific method used for a <a>watermarking proof</a> MUST be identified
using the <code>type</code> <a>property</a>.
</p>
<p>
Expand Down Expand Up @@ -2244,6 +2244,13 @@ <h3>Presentations</h3>
verifiable credential graphs</a> in a cryptographically <a>verifiable</a> format.
See Section <a href="#verifiable-credential-graphs"></a> for further details on
this topic.
</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>.
Comment on lines +2247 to +2253
Copy link
Member

@iherman iherman Nov 29, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

  1. 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 verifiableCredential term).
  2. 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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 😀.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, let us try to go the simple way and keep it as a URL... Let us see where this goes.

</dd>
<dt><var id="defn-holder">holder</var></dt>
<dd>
Expand Down Expand Up @@ -2278,7 +2285,8 @@ <h3>Presentations</h3>
</dl>

<p>
The example below shows a <a>verifiable presentation</a>:
The example below shows a <a>verifiable presentation</a> that uses
<a>watermarking proofs</a>:
</p>

<pre class="example nohighlight" title="Basic structure of a presentation">
Expand All @@ -2304,6 +2312,26 @@ <h3>Presentations</h3>
[[?VC-JOSE-COSE]] specification.
</p>

<p>
The example below shows a <a>verifiable presentation</a> that contains
<a>verifiable credentials</a> that are protected using <a>enveloping proofs</a>:
</p>

<pre class="example nohighlight" title="A presentation that contains verifiable credentials secured using enveloping proofs">
{
"@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"],
"envelopedVerifiableCredential": [
Copy link
Contributor

@OR13 OR13 Dec 4, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@iherman iherman Dec 5, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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==> .

"data:application/jwt;base64,QzVjV...RMjUK==",
"data:application/cwt;base64,ZmlOW...pYzMK="
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

]
}
</pre>

<section>
<h4>Presentations Using Derived Credentials</h4>

Expand Down Expand Up @@ -2381,7 +2409,7 @@ <h4>Presentations Including Holder Claims</h4>
mechanism as the <a>verifiable presentation</a>.
</p>

<pre class="example nohighlight" title="A verifiable presentation, secured with an embedded proof, with a self-asserted verifiable credential">
<pre class="example nohighlight" title="A verifiable presentation, secured with a watermarking proof, with a self-asserted verifiable credential">
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
Expand All @@ -2408,7 +2436,7 @@ <h4>Presentations Including Holder Claims</h4>
<a>verifiable presentation</a>.
</p>

<pre class="example nohighlight" title="A verifiable presentation, secured with an embedded proof, with a self-asserted verifiable credential about the verifiable presentation">
<pre class="example nohighlight" title="A verifiable presentation, secured with a watermarking proof, with a self-asserted verifiable credential about the verifiable presentation">
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
Expand Down Expand Up @@ -6528,7 +6556,7 @@ <h2>application/vc+ld+json</h2>
</p>

<p>
This media type can be used with credentials secured using an <a>external
This media type can be used with credentials secured using an <a>enveloping
proof</a>.
</p>
<p>
Expand Down Expand Up @@ -6590,7 +6618,7 @@ <h2>application/vp+ld+json</h2>

<p>
This media type can be used with presentations secured using an
<a>external proof</a>.
<a>enveloping proof</a>.
</p>
<p>
A [[JSON-LD]] context is expected to be present in the body of the document, and
Expand Down