[=Credentials=]（凭证）是我们日常生活中不可或缺的一部分：驾驶执照证明我们有能力驾驶机动车辆；大学学位证明我们的教育水平；政府颁发的护照在我们出国旅行时证明我们的公民身份。本规范提供了一种在 Web 上以加密安全、隐私保护和机器可验证的方式表达这些类型[=credentials=]的机制。这些[=credentials=]在物理世界中使用时为我们带来了诸多好处，但它们在 Web 上的使用仍然难以实现。
目前，在 Web 上以机器可读的方式表达教育资历、医疗数据、金融账户详情以及其他经第三方[=verified=]（验证）的个人信息仍然十分困难。在 Web 上表达数字[=credentials=]的挑战阻碍了我们从中获得与物理[=credentials=]在现实世界中相同的好处。
{
"@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": {
"id": "https://university.example/issuers/565049",
"name": "Example University",
"description": "A public university focusing on teaching examples."
},
"validFrom": "2015-05-10T12:30:00Z",
"name": "Example University Degree",
"description": "2015 Bachelor of Science and Arts Degree",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": "Bachelor of Science and Arts"
}
}
}
Names and descriptions also support expressing content in different languages.
To express a string with language and [=base direction=] information,
one can use an object that contains the `@value`, `@language`, and `@direction`
properties to express the text value, language tag, and base direction,
respectively. See
[[[#language-and-base-direction]]] for further information.
The `@direction` property in the examples below is not required
for the associated single-language strings, as their default directions are the
same as those set by the `@direction` value. We include the `@direction`
property here for clarity of demonstration and to make copy+paste+edit deliver
functional results. Implementers are encouraged to read the section on
String Internationalization
in the [[[JSON-LD11]]] specification.
{
"@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": {
"id": "https://university.example/issuers/565049",
"name": [{
"@value": "Example University",
"@language": "en"
}, {
"@value": "Université Exemple",
"@language": "fr"
}, {
"@value": "جامعة المثال",
"@language": "ar",
"@direction": "rtl"
}],
"description": [{
"@value": "A public university focusing on teaching examples.",
"@language": "en"
}, {
"@value": "Une université publique axée sur l'enseignement d'exemples.",
"@language": "fr"
}, {
"@value": ".جامعة عامة تركز على أمثلة التدريس",
"@language": "ar",
"@direction": "rtl"
}]
},
"validFrom": "2015-05-10T12:30:00Z",
"name": [{
"@value": "Example University Degree",
"@language": "en"
}, {
"@value": "Exemple de Diplôme Universitaire",
"@language": "fr"
}, {
"@value": "مثال الشهادة الجامعية",
"@language": "ar",
"@direction": "rtl"
}],
"description": [{
"@value": "2015 Bachelor of Science and Arts Degree",
"@language": "en"
}, {
"@value": "2015 Licence de Sciences et d'Arts",
"@language": "fr"
}, {
"@value": "2015 بكالوريوس العلوم والآداب",
"@language": "ar",
"@direction": "rtl"
}],
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "ExampleBachelorDegree",
"name": [{
"@value": "Bachelor of Science and Arts Degree",
"@language": "en"
}, {
"@value": "Licence de Sciences et d'Arts",
"@language": "fr"
}, {
"@value": "بكالوريوس العلوم والآداب",
"@language": "ar",
"@direction": "rtl"
}]
}
}
}
Expressing information related to multiple [=subjects=] in a
[=verifiable credential=] is possible. The example below specifies two
[=subjects=] who are spouses. Note the use of array notation to associate
multiple [=subjects=] with the `credentialSubject` property.
This specification defines the following [=property=] for expressing a
data schema, which an [=issuer=] can include in the [=verifiable credentials=]
that it issues:
These two classes of securing mechanisms are not mutually exclusive. Additional
securing mechanism specifications might also be defined according to the rules
in Section [[[#securing-mechanism-specifications]]].
Some selective disclosure schemes can share a subset of [=claims=]
derived from a [=verifiable credential=].
For an example of a ZKP-style [=verifiable presentation=] containing
derived data instead of directly embedded [=verifiable credentials=], see
Section [[[#zero-knowledge-proofs]]].
A basic claim expressing that Pat is over the age of 21.
The example below shows a [=verifiable presentation=] that embeds a
self-asserted [=verifiable credential=] holding [=claims=] about the
[=verifiable presentation=]. It is secured using the same mechanism as the
[=verifiable presentation=].
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"type": ["VerifiablePresentation", "ExamplePresentation"],
"id": "urn:uuid:313801ba-24b7-11ee-be02-ff560265cf9b",
"holder": "did:example:12345678",
"verifiableCredential": [{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.w3.org/ns/credentials/examples/v2"
],
"type": ["VerifiableCredential", "ExampleAssertCredential"],
"issuer": "did:example:12345678",
"credentialSubject": {
"id": "urn:uuid:313801ba-24b7-11ee-be02-ff560265cf9b",
"assertion": "This VP is submitted by the subject as evidence of a legal right to drive"
},
"proof": { ... }
}],
"proof": { ... }
}
所有[=entities=]期望[=verifiable data registry=]是防篡改的，并且是关于哪些数据由哪些[=entities=]控制的正确记录。这通常通过其发布方式实现。这可以是来自可信发布者的点对点协议、公开可访问的知名网站（带有内容哈希）、区块链等。当实体发布关于自身的元数据时，可以通过使用该实体的私钥保护来确保发布的完整性。
The [=holder=] expects the [=credential repository=] to store [=credentials=]
securely, to not release [=credentials=] to anyone other than the [=holder=]
(which may subsequently present them to a [=verifier=]), and to not corrupt nor
lose [=credentials=] while they are in its care.
This trust model differentiates itself from other trust models by ensuring
the following:
In the example above, the [=issuer=] specifies an automatic
`refreshService` that can be used by POSTing the [=verifiable credential=] to
the refresh service `url`. Note that this particular verifiable credential is
not intended to be shared with anyone except for the original issuer.
Placing a `refreshService` [=property=] in a
[=verifiable credential=] so that it is available to [=verifiers=] can
remove control and consent from the [=holder=] and allow the
[=verifiable credential=] to be issued directly to the [=verifier=],
thereby bypassing the [=holder=].
In the example above, the [=issuer=] is asserting that the legal basis
under which the [=verifiable credential=] has been issued is the
"professional qualifications directive" using the "Employment&Life" trust
framework, with a specific link to the policy.
This feature is expected to be used by government-issued [=verifiable
credentials=] to instruct digital wallets to limit their use to similar
government organizations in an attempt to protect citizens from unexpected use
of sensitive data. Similarly, some [=verifiable credentials=] issued by private
industry are expected to limit use to within departments inside the
organization, or during business hours. Implementers are urged to read more
about this evolving feature in the appropriate section of the Verifiable
Credentials Implementation Guidelines [[?VC-IMP-GUIDE]] document.
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json"
],
"id": "http://1edtech.edu/credentials/3732",
"type": [
"VerifiableCredential",
"OpenBadgeCredential"
],
"issuer": {
"id": "https://1edtech.edu/issuers/565049",
"type": "Profile"
},
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"type": "AchievementSubject",
"name": "Alice Smith",
"activityEndDate": "2023-12-02T00:00:00Z",
"activityStartDate": "2023-12-01T00:00:00Z",
"awardedDate": "2024-01-01T00:00:00Z",
"achievement": [{
"id": "urn:uuid:d46e8ef1-c647-419b-be18-5e045d1c4e64",
"type": ["Achievement"],
"name": "Basic Barista Training",
"criteria": {
"narrative": "Team members are nominated for this badge by their supervisors, after passing the Basic Barista Training course."
},
"description": "This achievement certifies that the bearer is proficient in basic barista skills."
}]
},
"evidence": [{
// url to an externally hosted evidence file/artifact
"id": "https://videos.example/training/alice-espresso.mp4",
"type": ["Evidence"],
"name": "Talk-aloud video of double espresso preparation",
"description": "This is a talk-aloud video of Alice demonstrating preparation of a double espresso drink.",
// digest hash of the mp4 video file
"digestMultibase": "uELq9FnJ5YLa5iAszyJ518bXcnlc5P7xp1u-5uJRDYKvc"
}
]
}
In the `evidence` example above, the [=issuer=] is asserting that they have
video of the [=subject=] of the [=credential=] demonstrating the achievement.
The `evidence` [=property=] provides information that is different from and
information to the securing mechanism used. The `evidence` [=property=] is
used to express supporting information, such as documentary evidence, related to
the [=verifiable credential=]. In contrast, the securing mechanism is used to
express machine-verifiable mathematical proofs related to the authenticity of
the [=issuer=] and integrity of the [=verifiable credential=]. For more
information about securing mechanisms, see Section [[[#securing-mechanisms]]].
A visual example of the relationship between credentials and derived
credentials in a ZKP [=presentation=].
An example of a [=verifiable credential=] and a [=verifiable presentation=]
using the [[[?VC-DI-BBS]]] unlinkable selective disclosure securing mechanism is
shown below.
The example above is a [=verifiable credential=] where the [=issuer=] has
enabled a BBS-based unlinkable disclosure scheme to create a base proof that
can then be used by the [=holder=] to create a derived proof that reveals only
particular pieces of information from the original [=verifiable credential=].
希望检查`dateTimeStamp`值有效性的实现者可以使用下面提供的正则表达式，该表达式为方便起见从[XMLSCHEMA11-2]规范中复制。为避免疑义，[[XMLSCHEMA11-2]]中的正则表达式是规范性定义。建议实现者注意，并非所有通过下面正则表达式的`dateTimeStamp`值都是有效的时间点。例如，下面的正则表达式允许每月31天，这允许闰年和闰秒以及在不存在这些天的地方出现天数。也就是说，生成`dateTimeStamp`值的现代系统库通常在生成有效`dateTimeStamp`值方面没有错误。正则
expression shown below (minus the whitespace included here for readability),
is often adequate when processing library-generated dates and times on
modern systems.
In order to avoid collisions regarding how the following properties are used,
implementations MUST specify a `type` property in the value associated with the
reserved property. For more information related to adding `type` information,
see Section [[[#types]]].
Reserved Property
Description
`confidenceMethod`
A property used for specifying one or more methods that a verifier might use to
increase their confidence that the value of a property in or of a verifiable
credential or verifiable presentation is accurate. The associated vocabulary
URL MUST be `https://www.w3.org/2018/credentials#confidenceMethod`. Implementers
that are interested in learning more about confidence method, including examples
of usage, can refer to the [[[?VC-CONFIDENCE-METHOD]]] specification.
`renderMethod`
A property used for specifying one or more methods to render a credential into a
visual, auditory, haptic, or other format. The associated vocabulary URL MUST be
`https://www.w3.org/2018/credentials#renderMethod`. Implementers that are
interested in learning more about render method, including examples of usage, can
refer to the [[[?VC-RENDER-METHOD]]] specification.
An unofficial list of specifications that are associated with the extension
points defined in this specification, as well as the reserved extension points
defined in this section, can be found in the [[[?VC-EXTENSIONS]]]. Items in the
directory that refer to reserved extension points SHOULD be treated as
experimental.
rules when documenting transformations that enable compatibility with the
Verifiable Credentials ecosystem. The transformation specification —
MUST identify whether the transformation to this data model is one-way-only or
round-trippable.
MUST preserve the `@context` values when performing round-trippable
transformation.
MUST result in a [=conforming document=] when transforming to the data
model described by this specification.
MUST specify a registered media type for the input document.
SHOULD provide a test suite that demonstrates that the specified transformation
algorithm to the data model in this specification results in
a [=conforming document=].
SHOULD ensure that all semantics used in the transformed
[=conforming document=] follow best practices for Linked Data. See
Section [[[#getting-started]]], Section
[[[#extensibility]]], and Linked Data Best Practices [[?LD-BP]]
for additional guidance.
Using these [=graphs=] has a concrete effect when performing JSON-LD
processing, which properly separates graph node identifiers in one graph from
those in another graph. Implementers that limit their inputs to
application-specific JSON-LD documents will also need to keep this in mind if
they merge data from one [=verifiable credential=] with data from another,
such as when the `credentialSubject.id` is the same in both [=verifiable
credentials=], but the object might contain objects of the "Jane Doe" form
described in the previous paragraph. It is important to not merge objects that
seem to have similar properties but do not contain an `id` property that uses a
global identifier, such as a URL.
Securing mechanism specifications MUST provide a verification algorithm that
returns the information in the [=conforming document=] that has been secured, in
isolation, without including any securing mechanism information, such as `proof` or
JOSE/COSE header parameters and signatures. Verification algorithms MAY return
additional information that might be helpful (for example, during validation or
for debugging purposes), such as details of the securing mechanism. A verification
algorithm MUST provide an interface that receives a media type ([=string=]
|inputMediaType|) and input data ([=byte sequence=] or [=map=] |inputData|).
Securing mechanism specifications MAY provide algorithms and interfaces in
addition to the ones specified in this document. The verification algorithm
returns a verification result with at least the following [=struct/items=]:
[=boolean=] |verified|
A verification status whose value is `true` if the verification succeeded and
`false` if it did not.
[=map=] |verifiedDocument|
A document that only contains information that was successfully secured.
[=string=] |mediaType|
A media type as defined in [[RFC6838]].
Securing mechanism specifications SHOULD provide integrity protection for any
information referenced by a URL that is critical to validation. Mechanisms that
can achieve this protection are discussed in Section
[[[#integrity-of-related-resources]]] and Section
[[[#base-context]]].
A securing mechanism specification that creates a new type of [=embedded proof=]
MUST specify a [=property=] that relates the [=verifiable credential=] or
[=verifiable presentation=] to a [=proof graph=].
The requirements on the securing mechanism are as follow:
The securing mechanism MUST define all terms used by the [=proof graph=]. For
example, the mechanism could define vocabulary specifications and `@context`
files in the same manner as they are used by this specification.
The securing mechanism MUST secure all graphs in the [=verifiable credential=]
or the [=verifiable presentation=], except for any [=proof graphs=] securing
the [=verifiable credential=] or the [=verifiable presentation=] itself.
The last requirement means that the securing mechanism secures the [=default
graph=] and, for [=verifiable presentations=], each [=verifiable credential=]
of the presentation, together with their respective [=proof graphs=].
See also [[[#info-graph-vp]]] or [[[#info-graph-vp-mult-creds]]].
The `proof` property as defined in [[VC-DATA-INTEGRITY]] MAY be used by the
embedded securing mechanism.
Securing mechanism specifications SHOULD register the securing mechanism in the
Securing Mechanisms
section of the [[[?VC-EXTENSIONS]]] document.
There are multiple acceptable securing mechanisms, and this specification does
not mandate any particular securing mechanism for use with
[=verifiable credentials=] or [=verifiable presentations=].
The Working Group that produced this specification did standardize two
securing mechanism options, which are:
[[[VC-DATA-INTEGRITY]]] [[VC-DATA-INTEGRITY]] and [[[VC-JOSE-COSE]]]
[[VC-JOSE-COSE]]. Other securing mechanisms that are known to the community
can be found in the
Securing Mechanisms
section of the [[[?VC-EXTENSIONS]]] document.
The `@id` and `@type` keywords are aliased to
`id` and `type` respectively, enabling developers to use
this specification as idiomatic JSON.
Data types, such as integers, dates, units of measure, and URLs, are
automatically typed to provide stronger type guarantees for use cases that
require them.
The `verifiableCredential` [=property=]
is defined as a
JSON-LD 1.1 graph
container. This requires the creation of [=named graphs=], used to isolate
sets of data asserted by different entities. This ensures, for example, proper
cryptographic separation between the data graph provided by each [=issuer=]
and the one provided by the [=holder=] presenting the [=verifiable
credential=] to ensure the provenance of the information for each graph is
preserved.
The `@protected` properties feature of [[[!JSON-LD11]]] is used to ensure that
terms defined by this specification cannot be overridden. This means that as
long as the same `@context` declaration is made at the top of a [=verifiable
credential=] or [=verifiable presentation=], interoperability is guaranteed for
all terms understood by users of the data model whether or not they use a
[[[!JSON-LD11]]] processor.
In-line declaration of JSON-LD keywords in the `@context` value that globally
modify document term and value processing, such as setting `@base` or `@vocab`
Use of JSON-LD contexts that override declarations in previous contexts, such as
resetting `@vocab`
In-line declaration of JSON-LD contexts in the `@context` property
Use of full URLs for JSON-LD terms and types (for example,
`https://www.w3.org/2018/credentials#VerifiableCredential` or
`https://vocab.example/myvocab#SomeNewType`) instead of the short forms of
any such values (for example, `VerifiableCredential` or `SomeNewType`) that are
explicitly defined in JSON-LD `@context` mappings (for example, in
`https://www.w3.org/ns/credentials/v2`)
While this specification cautions against the use of `@vocab`, there are
legitimate uses of the feature, such as to ease experimentation, development,
and localized deployment. If an application developer wants to use `@vocab` in
production, which is advised against to reduce term collisions and leverage the
benefits of semantic interoperability, they are urged to understand that any use
of `@vocab` will disable reporting of "undefined term" errors, and
later use(s) will override any previous `@vocab` declaration(s). Different values
of `@vocab` can change the semantics of the information contained in the document,
so it is important to understand whether and how these changes will affect the
application being developed.
In general, a JSON array is ordered, while a JSON-LD array is not ordered unless
that array uses the `@list` keyword.
While it is possible to use this data model by performing [=type-specific
credential processing=], those who do so and make use of arrays need to be aware
that unless the above guidance is followed, the order of items in an array
are not guaranteed in JSON-LD. This might lead to unexpected behavior.
If JSON structure or ordering is important to your application, we recommend you
mark such elements as `@json` via an `@context` that is specific to your
use case. An example of such a declaration is shown below.
When the context shown above is used in the example below, by including the
`https://website.example/matrix/v1` context in the `@context` property, the
value in `credentialSubject.matrix` retains its JSON semantics; the exact order
of all elements in the two dimensional matrix is preserved.
A web server defaults to `text/plain` or `application/octet-stream` when a file
extension is not available and it cannot determine the media type.
A developer adds a file extension that leads to a media type that is less
specific than the content of the file. For example, `.json` could result in a
media type of `application/json` and `.jsonld` might result in a media type of
`application/ld+json`.
A protocol requires a less precise media type for a particular transaction; for
example, `application/json` instead of `application/vp`,
Implementers are urged to not raise errors when it is possible to determine the
intended media type from a payload, provided that the media type used is
acceptable in the given protocol. For example, if an application only accepts
payloads that conform to the rules associated with the `application/vc` media
type, but the payload is tagged with `application/json` or `application/ld+json`
instead, the application might perform the following steps to determine whether
the payload also conforms to the higher precision media type:
Parse the payload as a JSON document.
Ensure that the first element of the `@context` property matches
`https://www.w3.org/ns/credentials/v2`.
Assume an `application/vp` media type if the JSON document contains a top-level
`type` property containing a `VerifiablePresentation` element. Additional
subsequent checks are still expected to be performed (according to this
specification) to ensure the payload expresses a conformant
[=verifiable presentation=].
Assume an `application/vc` media type if the JSON document contains a top-level
`type` property containing a `VerifiableCredential` element. Additional
subsequent checks are still expected to be performed (according to this
specification) to ensure the payload expresses a conformant
[=verifiable credential=].
Whenever possible, implementers are advised to use the most precise (the highest
precision) media type for all payloads defined by this specification.
Implementers are also advised to recognize that a payload tagged with a lower
precision media type does not mean that the payload does not meet the rules
necessary to tag it with a higher precision type. Similarly, a payload tagged
with a higher precision media type does not mean that the payload will meet the
requirements associated with the media type. Receivers of payloads, regardless
of their associated media type, are expected to perform appropriate checks to
ensure that payloads conform with the requirements for their use in a given
system.
HTTP clients and servers use media types associated with [=verifiable
credentials=] and [=verifiable presentations=] in accept headers and when
indicating content types. Implementers are warned that HTTP servers might ignore
the accept header and return another content type, or return an error code such
as `415 Unsupported Media Type`.
General JSON-LD processing is defined as a mechanism that uses a
JSON-LD software library to process a [=conforming document=] by performing
various transformations.
Type-specific credential processing is defined as a lighter-weight
mechanism for processing [=conforming documents=], that doesn't require
a JSON-LD software library. Some consumers of [=verifiable credentials=]
only need to consume credentials with specific types. These consumers can use
type-specific credential processing instead of generalized processing. Scenarios
where type-specific credential processing can be desirable include, but are not
limited to, the following:
Before applying a securing mechanism to a [=conforming document=], or after
verifying a [=conforming document=] protected by a securing mechanism, to
ensure
data integrity.
When performing JSON Schema validation, as described in Section
[[[#data-schemas]]].
When serializing or deserializing [=verifiable credentials=] or
[=verifiable presentations=] into systems that store or index their contents.
When operating on [=verifiable credentials=] or [=verifiable
presentations=] in a software application, after verification or validation
is performed for securing mechanisms that require
[=general JSON-LD processing=].
When an application chooses to process the media type using the `+json`
structured media type suffix.
That is, [=type-specific credential processing=] is allowed as long as the
document being consumed or produced is a [=conforming document=].
If [=type-specific credential processing=] is desired, an implementer is advised
to follow this rule:
Ensure that all values associated with a `@context` property are in the expected
order, the contents of the context files match known good cryptographic hashes
for each file, and domain experts have deemed that the contents are appropriate
for the intended use case.
Using static context files with a JSON Schema is one acceptable approach to
implementing the rule above. This can ensure proper term identification,
typing, and order, when performing [=type-specific credential processing=].
The rule above guarantees semantic interoperability between the two processing
mechanisms for mapping literal JSON keys to URIs via the `@context` mechanism.
While [=general JSON-LD processing=] can use previously unseen `@context`
values provided in its algorithms to verify that all terms are correctly
specified, implementations that perform [=type-specific credential
processing=] only accept specific `@context` values which the implementation
is engineered ahead of time to understand, resulting in the same semantics
without invoking any JSON-LD APIs. In other words, the context in which the data
exchange happens is explicitly stated for both processing mechanisms by using
`@context` in a way that leads to the same [=conforming document=] semantics.
如果|verifyProof|函数期望[=byte sequence=]，向算法提供|inputMediaType|和|inputData|。如果|verifyProof|函数期望[=map=]，提供|inputMediaType|和给定|inputData|的[=parse JSON bytes to an Infra value=]的结果。将|result|设置为调用|verifyProof|函数的结果。如果调用成功，|result|将包含|status|、|document|、|mediaType|、|controller|、|controlledIdentifierDocument|、|warnings|和|errors|属性。
它增加了使用此数据模型时的安全攻击面，因为天真地处理 HTML 可能导致攻击者在数据生产过程中某一点注入的 `script` 标签被执行。
如果实施者认为需要使用 HTML 或其他能够包含可执行脚本的标记语言来解决特定用例，建议他们分析攻击者如何使用标记对标记的消费者发起注入攻击。此分析之后应主动部署针对已识别攻击的缓解措施，例如在没有网络访问能力的沙箱中运行 HTML 渲染引擎。
无障碍性注意事项
实施者在处理本规范中描述的数据时应当（SHOULD）了解许多无障碍性注意事项。与任何 Web 标准或协议的实现一样，忽视无障碍性问题会使大量人口无法使用此信息。遵循无障碍性指南和标准（如 [[WCAG21]]）以确保所有人（无论能力如何）都能使用此数据非常重要。当建立使用密码学的系统时，这一点尤其重要，因为密码学历史上为辅助技术带来了问题。
"title": [
{
"@value": "HTML and CSS: Designing and Creating Websites",
"@language": "en"
},
{
"@value": "HTML و CSS: تصميم و إنشاء مواقع الويب",
"@language": "ar",
"@direction": "rtl"
}
]
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://achievement.example/multilingual/v2"
],
"type": [ "VerifiableCredential", "ExampleAchievementCredential" ],
"issuer": {
"id": "did:example:2g55q912ec3476eba2l9812ecbfe",
"type": "Profile"
},
"validFrom": "2024-03-14T22:32:52Z",
"validUntil": "2025-01-01T00:00:00Z",
"credentialSubject": {
"type": [ "AchievementSubject" ],
"achievement": {
"id": "urn:uuid:9a652678-4616-475d-af12-aca21cfbe06d",
"type": [ "Achievement" ],
"name": {
"en": "Successful installation of the Example application",
"es": "Instalación exitosa de la aplicación Example"
},
"criteria": {
"narrative": {
"es": "Instaló exitosamente de la aplicación Example.",
"en": "Successfully installed the Example application."
}
}
}
}
}
It is possible to confirm the cryptographic digests listed above by running
a command like the following, replacing `<DOCUMENT_URL>`
with the appropriate value, through a modern UNIX-like OS command line interface:
`curl -sL -H "Accept: application/ld+json" <DOCUMENT_URL> | openssl dgst -sha256`
See the ABNF
grammar, defining the `integrity` attribute in the [[SRI]] specification,
for the restrictions on the string format.
The value space
A (possibly empty) list of (alg,val) pairs, where alg identifies a
hash function, and val is an integer as a standard mathematical concept.
The lexical-to-value mapping
Any element of the lexical space is mapped to the value space by following the
parse metadata algorithm
based on the ABNF
grammar in the [[SRI]] specification.
The canonical mapping
The canonical mapping consists of the lexical-to-value mapping.
Resources that use the `application/vc` media type are required to conform to
all of the requirements for the `application/ld+json` media type and are
therefore subject to the same encoding considerations specified in Section 11
of [[[RFC7159]]].
Resources that use the `application/vp` media type are required to conform to
all of the requirements for the `application/ld+json` media type and are
therefore subject to the same encoding considerations specified in Section 11
of [[[RFC7159]]].
Abhishek Mahadevan Raju,
Adam C. Migus,
Addison Phillips,
Adrian Gropper,
Aisp-GitHub,
Alen Horvat,
Alexander Mühle,
AlexAndrei98,
Allen Brown,
Amy Guy,
Andor Kesselman,
Andres Paglayan,
Andres Uribe,
Andrew Hughes,
Andrew Jones,
Andrew Whitehead,
Andy Miller,
Anil John,
Anthony Camilleri,
Anthony Nadalin,
Benjamin Collins,
Benjamin Goering,
Benjamin Young,
Bert Van Nuffelen,
Bohdan Andriyiv,
Brent Zundel,
Brian Richter,
Bruno Zimmermann,
caribouW3,
cdr,
Chaoxinhu,
Charles "Chaals" McCathieNevile,
Charles E. Lehner,
Chris Abernethy,
Chris Buchanan,
Christian Lundkvist,
Christine Lemmer-Webber,
Christoph Lange,
Christopher Allen,
Christopher Lemmer Webber,
ckennedy422,
Clare Nelson,
confiks,
Dan Brickley,
Daniel Buchner,
Daniel Burnett,
Daniel Hardman,
Darrell O'Donnell,
Dave Longley,
David Ammouial,
David Chadwick,
David Ezell,
David Hyland-Wood,
David I. Lehn,
David Janes,
David Waite,
Denis Ah-Kang,
Denisthemalice,
Devin Rousso,
Dmitri Zagidulin,
Dominique Hazael-Massieux,
Drummond Reed,
Emmanuel,
enuoCM,
Eric Elliott,
Eric Korb,
Eric Prud'hommeaux,
etaleo,
Evstifeev Roman,
Fabricio Gregorio,
Filip Kolarik,
Gabe Cohen,
Ganesh Annan,
George Aristy,
glauserr,
Golda Velez,
Grace Huang,
Grant Noble,
Greg Bernstein,
Gregg Kellogg,
Heather Vescent,
Henry Andrews,
Henry Story,
Ian B. Jacobs,
Ilan,
Isaac Henderson,
isaackps,
Iso5786,
Ivan Herman,
Jace Hensley,
Jack Tanner,
James Schoening,
Janina Sajka,
Jan Forster Cognizone,
Jeff Burdges,
Jeffrey Yasskin,
Jim Masloski,
Jim St.Clair,
Joe Andrieu,
Joel Gustafson,
Joel Thorstensson,
John Tibbetts,
Jonathan Holt,
José San Juan,
Juan Caballero,
Julien Fraichot,
Justin Richer,
Kaan Uzdoğan,
Kaliya Young,
Kazuyuki Ashimura,
Ken Ebert,
Kendall Weihe,
Kerri Lemoie,
Kevin Dean,
Kevin Griffin,
Kim Hamilton Duffy,
Konstantin Tsabolov,
Kristijan Sedlak,
Kristina Yasuda,
Kyle Den Hartog,
Lal Chandran,
Lance,
Lautaro Dragan,
Leonard Rosenthol,
Liam Missin,
Liam Quin,
Line Kofoed,
Lionel Wolberger,
Logan Porter,
Lovesh Harchandani,
Lukas J. Han,
Mahmoud Alkhraishi,
Maik Riechert,
Manu Sporny,
Marcel Jackisch,
Mark Foster,
Mark Harrison,
Mark Moir,
Markus Sabadello,
Martin Thomson,
Marty Reed,
Matt Peterson,
Matt Stone,
Matthew Peterson,
Matthieu Bosquet,
Matti Taimela,
Melvin Carvalho,
Michael B. Jones,
Michael Herman,
Michael Lodder,
Michael Richardson,
Mike Prorock,
Mike Varley,
Mircea Nistor,
MIZUKI Sonoko / Igarashi,
nage,
Nate Otto,
Nathan George,
Niclas Mietz,
Niko Lockenvitz,
Nikos Fotiou,
Nis Jespersen,
Oliver Terbu,
Pat McBennett,
Patrick St-Louis,
Paul Bastian,
Paul F. Dietrich,
Paulo Jorge Q. Ferreira,
Pelle Braendgaard,
Pete Rowley,
Phil Archer,
Phillip Long,
Pierre-Antoine Champin,
Rajesh Rathnam,
Ralph Swick,
Renato Iannella,
Reto Gmür,
Reza Soltani,
Richard Bergquist,
Richard Ishida,
Richard Varn,
Rieks Joosten,
RorschachRev,
Ryan Grant,
Samuel Müller,
Samuel Smith,
Sarven Capadisli,
Sebastian Crane,
Sebastian Elfors,
Shawn Butterfield,
Shigeya Suzuki,
Sho Nakatani,
Shuji Kamitsuna,
Snorre Lothar von Gohren Edwin,
Sten Reijers,
Stephen Curran,
Steve Huguenin,
Steve McCown,
Steven Rowat,
Taro,
tcibm,
Ted Thibodeau Jr.,
Tim Bouma,
Timo Glastra,
Tobias Käfer,
Tobias Looker,
Tom Jones,
Torsten Lodderstedt,
Tzviya Siegman,
Victor Dods,
Vincent Kelleher,
Vladimir Alexiev,
Víctor Herraiz Posada,
Wayne Chang,
whatisthejava,
Will Abramson,
William Entriken, and
Yancy Ribbens.
