Skip to content

Commit 0402b0c

Browse files
ihermaniherman
committed
Merge branch 'main' into vocab-change-termsOfUse-no-longer-reserved
* main: Added the new vocabulary file for undefined terms (#1536) Add explanation of securing mechanism examples. Remove mention of ZKP schemas since we have no examples to point to. Reformat status spec requirements in Status section.
2 parents ad8e6b0 + 4898734 commit 0402b0c

File tree

3 files changed

+116
-147
lines changed

3 files changed

+116
-147
lines changed

‎index.html

Lines changed: 27 additions & 67 deletions
Original file line numberDiff line numberDiff line change
@@ -2172,24 +2172,16 @@ <h3>Status</h3>
21722172
</p>
21732173

21742174
<p>
2175-
Specification authors that create status schemes are provided the following
2176-
guideline:
2175+
Credential status specifications MUST NOT enable tracking of individuals, such
2176+
as an [=issuer=] being notified (either directly or indirectly) when a
2177+
[=verifier=] is interested in a specific [=holder=] or [=subject=]. Unacceptable
2178+
approaches include "phoning home," such that every use of a credential contacts
2179+
the [=issuer=] of the credential to check the status for a specific individual,
2180+
or "pseudonymity reduction", such that every use of the credential causes a
2181+
request for information from the [=issuer=] that can be used by the [=issuer=]
2182+
to deduce [=verifier=] interest in a specific individual.
21772183
</p>
21782184

2179-
<ul>
2180-
<li>
2181-
Status schemes MUST NOT be implemented in ways that enable tracking of
2182-
individuals, such as an [=issuer=] being notified (either directly or
2183-
indirectly) when a [=verifier=] is interested in a particular [=holder=]
2184-
or [=subject=]. Unacceptable approaches include "phoning home," such that
2185-
every use of a credential contacts the [=issuer=] of the credential to
2186-
check the status for a specific individual, or "pseudonymity reduction,"
2187-
such that every use of the credential causes a request for information
2188-
from the [=issuer=] that can be used by the [=issuer=] to deduce
2189-
[=verifier=] interest in a specific individual.
2190-
</li>
2191-
</ul>
2192-
21932185
</section>
21942186

21952187
<section>
@@ -2240,8 +2232,7 @@ <h3>Data Schemas</h3>
22402232
</p>
22412233
<p>
22422234
If multiple schemas are present, validity is determined according to the
2243-
processing rules outlined by each associated `credentialSchema`
2244-
`type` property.
2235+
processing rules outlined by each associated `type` property.
22452236
</p>
22462237
</dd>
22472238
</dl>
@@ -2291,57 +2282,12 @@ <h3>Data Schemas</h3>
22912282
</pre>
22922283

22932284
<p>
2294-
In the example above, the [=issuer=] is specifying a
2295-
`credentialSchema`, which points to a [[?VC-JSON-SCHEMA]] file that
2296-
can be used by a [=verifier=] to determine whether the
2297-
[=verifiable credential=] is well-formed.
2298-
</p>
2299-
2300-
<p class="note"
2301-
title="See Implementation Guide for details on JSON Schema">
2302-
For information about linkages to JSON Schema [[?VC-JSON-SCHEMA]] or other
2303-
optional schema validation mechanisms, see the [[[VC-IMP-GUIDE]]] document.
2304-
</p>
2305-
2306-
<p>
2307-
Data schemas can also be used to specify mappings to other formats, such as
2308-
those used to perform zero-knowledge proofs. For more information on using the
2309-
`credentialSchema` [=property=] with zero-knowledge proofs,
2310-
see Section [[[#zero-knowledge-proofs]]].
2285+
In the example above, the [=issuer=] is specifying two `credentialSchema`
2286+
objects, each of which point to a JSON Schema [[?VC-JSON-SCHEMA]] file that can
2287+
be used by a [=verifier=] to determine whether the [=verifiable credential=] is
2288+
well-formed.
23112289
</p>
23122290

2313-
<pre class="example nohighlight" title="Usage of the credentialSchema property to perform zero-knowledge validation">
2314-
{
2315-
"@context": [
2316-
"https://www.w3.org/ns/credentials/v2",
2317-
"https://www.w3.org/ns/credentials/examples/v2"
2318-
],
2319-
"id": "http://university.example/credentials/3732",
2320-
"type": ["VerifiableCredential", "ExampleDegreeCredential"],
2321-
"issuer": "https://university.example/issuers/14",
2322-
"validFrom": "2010-01-01T19:23:24Z",
2323-
"credentialSubject": {
2324-
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
2325-
"degree": {
2326-
"type": "ExampleBachelorDegree",
2327-
"name": "Bachelor of Science and Arts"
2328-
}
2329-
},
2330-
<span class="highlight">"credentialSchema": {
2331-
"id": "https://example.org/examples/degree",
2332-
"type": "ZkpExampleSchema2018"
2333-
}</span>
2334-
}
2335-
</pre>
2336-
2337-
<p>
2338-
In the example above, the [=issuer=] is specifying a
2339-
`credentialSchema` pointing to a means of transforming the input data
2340-
into a format which can then be used by a [=verifier=] to determine whether
2341-
the proof provided with the [=verifiable credential=] is well-formed.
2342-
</p>
2343-
2344-
23452291
</section>
23462292

23472293
<section>
@@ -2400,6 +2346,13 @@ <h3>Securing Mechanisms</h3>
24002346
}
24012347
</pre>
24022348

2349+
<p>
2350+
The [=embedded proof=] above secures the original [=credential=] by decorating
2351+
the original data with a digital signature via the `proof` property, resulting
2352+
in a [=verifiable credential=] that is easy to manage in modern programming
2353+
environments and database systems.
2354+
</p>
2355+
24032356
<pre class="example nohighlight"
24042357
title="A verifiable credential that uses an enveloping proof in SD-JWT format">
24052358
eyJhbGciOiJFUzM4NCIsImtpZCI6IkdOV2FBTDJQVlVVMkpJVDg5bTZxMGM3U3ZjNDBTLWJ2UjFTT0
@@ -2440,6 +2393,13 @@ <h3>Securing Mechanisms</h3>
24402393
WyJ1Ynd6bi1kS19tMzRSMGI0SG84QTBBIiwgInR5cGUiLCAiQmFjaGVsb3JEZWdyZWUiXQ
24412394
</pre>
24422395

2396+
<p>
2397+
The [=enveloping proof=] above secures the original [=credential=] by
2398+
encapsulating the original data in a digital signature envelope, resulting in a
2399+
[=verifiable credential=] that can be processed using tooling that understands
2400+
the SD-JWT format.
2401+
</p>
2402+
24432403
</section>
24442404

24452405
<section>

‎vocab/credentials/v2/issuer-dependent.html

Lines changed: 0 additions & 80 deletions
This file was deleted.

‎vocab/credentials/v2/undefined-term.html

Lines changed: 89 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,89 @@
1+
<html lang="en">
2+
<head>
3+
<meta charset='utf-8'/>
4+
<title>Verifiable Credentials Undefined Terms</title>
5+
<script class="remove" src="https://www.w3.org/Tools/respec/respec-w3c"></script>
6+
<script>
7+
function remove_status_remark() {
8+
const sotd = document.getElementById("sotd");
9+
const p = sotd.getElementsByTagName('p')[0];
10+
sotd.removeChild(p);
11+
}
12+
</script>
13+
<script class="remove">
14+
var respecConfig = {
15+
specStatus: "base",
16+
shortName: "ns/credentials/undefined-term",
17+
thisVersion: "https://www.w3.org/ns/credentials/undefined-term",
18+
doJsonLd: true,
19+
editors: [{
20+
name: "Ivan Herman",
21+
url: "https://www.w3.org/People/Ivan/",
22+
company: "W3C",
23+
w3cid: 7382,
24+
orcid: "0000-0003-0782-2704",
25+
companyURL: "https://www.w3.org",
26+
note: "v2.0"
27+
}],
28+
postProcess : [remove_status_remark],
29+
inlineCSS: true,
30+
doRDFa: false,
31+
noIDLIn: true,
32+
noLegacyStyle: false
33+
};
34+
</script>
35+
</head>
36+
<body>
37+
<section id="abstract">
38+
<p>
39+
This is the namespace document for the undefined-term properties used in a
40+
Verifiable Credential [[vc-data-model-2.0]]
41+
</p>
42+
</section>
43+
<section id="sotd">
44+
<p>
45+
This namespace has been defined by the <a href="https://www.w3.org/2017/vc/WG/">W3C Verifiable Credentials Working Group</a>.
46+
Comments regarding this document are welcome. Please file issues
47+
directly on <a href="https://github.com/w3c/vc-data-model/issues/">GitHub</a>, or send them to
48+
<a href="mailto:[email protected]">[email protected]</a>
49+
(<a href="mailto:[email protected]?subject=subscribe">subscribe</a>,
50+
<a href="https://lists.w3.org/Archives/Public/public-vc-comments/">archives</a>).
51+
</p>
52+
</section>
53+
<section id="conformance"></section>
54+
<section>
55+
<h2>Undefined Terms</h2>
56+
<p>
57+
The <a href="https://www.w3.org/TR/vc-data-model-2.0/#base-context">base
58+
context</a> of a Verifiable Credential, as defined in [[[vc-data-model-2.0]]]
59+
[[vc-data-model-2.0]], provides a mapping from the standard terms used in
60+
credentials to the vocabulary items defined by the Verifiable Credentials
61+
Working Group, through different vocabularies such as the <a
62+
href="https://www.w3.org/2018/credentials/">Verifiable Credentials
63+
Vocabulary</a>. Applications using additional, application-specific terms
64+
of their own are encouraged to create their own formal vocabularies and
65+
corresponding JSON-LD context definitions, to ensure the interoperability
66+
of the credentials they produce and/or consume.
67+
</p>
68+
69+
<p>
70+
There may be cases, however, where the creation of such formal vocabularies and
71+
context definitions is too much of a burden, such as for closed applications,
72+
experiments, or examples. The <a
73+
href="https://www.w3.org/ns/credentials/undefined-term/v2">Undefined Terms
74+
context</a> has been constructed in such a way that issuers may use new,
75+
hitherto undefined terms by adding this context to their Verifiable Credentials,
76+
which will cause such terms to be mapped onto URLs of the form
77+
`https://www.w3.org/ns/credentials/undefined-term#TERM`. If a conforming
78+
document does not use JSON-LD Contexts that define all terms used, it is
79+
required to include `https://www.w3.org/ns/credentials/undefined-terms/v2` as
80+
the last value in the `@context` property.
81+
</p>
82+
83+
<p>
84+
This document provides a proper landing place for those URLs, without any additional definitions for the terms themselves.
85+
</p>
86+
</section>
87+
88+
</body>
89+
</html>

0 commit comments

Comments
 (0)