Credentials are a part of our daily lives; driver's licenses are used to
assert that we are capable of operating a motor vehicle, university degrees
can be used to assert our level of education, and government-issued passports
enable us to travel between countries. This specification provides a mechanism
to express these sorts of credentials on the Web in a way that is
cryptographically secure, privacy respecting, and machine-verifiable.
현재 문서의 상태
This is a
preview
Do not attempt to implement this version of the specification. Do not
reference this version as authoritative in any way.
Instead, see
https://w3c.github.io/vc-data-model/ for the Editor's draft.
이 부분은 현재 문서의 발행 당시 상태에 대해
기술합니다. 다른 문서가 이 문서를 대체할 수 있습니다. W3C 발행 문서의 최신
목록 및 테크니컬 리포트 최신판을 https://www.w3.org/TR/ 의
W3C technical reports index 에서
열람할 수 있습니다.
The Working Group thanks the following individuals not only for their
contributions toward the content of this document, but also for yeoman's work
in this standards community that drove changes, discussion, and consensus among
a sea of varied opinions: Matt Stone, Gregg Kellogg, Ted Thibodeau Jr, Oliver
Terbu, Joe Andrieu, David I. Lehn, Matthew Collier, and Adrian Gropper.
Work on this specification has been supported by the Rebooting the
Web of Trust community facilitated by Christopher Allen, Shannon Appelcline,
Kiara Robles, Brian Weller, Betty Dhamers, Kaliya Young, Manu Sporny,
Drummond Reed, Joe Andrieu, Heather Vescent, Kim Hamilton Duffy, Samantha Chase,
and Andrew Hughes. The participants in the Internet Identity Workshop,
facilitated by Phil Windley, Kaliya Young, Doc Searls, and Heidi Nobantu Saul,
also supported the refinement of this work through numerous working sessions
designed to educate about, debate on, and improve this specification.
The Working Group also thanks the Chairs, Dan Burnett and Matt Stone, as
well as our W3C Staff Contact, Kazuyuki Ashimura, for their expert
management and steady guidance of the group through the W3C standardization
process.
Portions of the work on this specification have been funded by the
United States Department of Homeland Security's Science and Technology
Directorate under contract HSHQDC-17-C-00019. The content of this specification
does not necessarily reflect the position or the policy of the U.S. Government
and no official endorsement should be inferred.
Comments regarding this document are welcome by the W3C Advisory Committee,
but readers should be aware that the Candidate Recommendation comment period
regarding the rest of this document has ended and the Working Group is
unlikley to make substantive modifications to the specification at this stage.
Please file issues directly on
GitHub,
or send them to
public-vc-comments@w3.org
(subscribe,
archives).
The Working Group has received implementation feedback showing that there are
at least two implementations for each normative feature in the specification.
The group has obtained reports from nine (9) implementations. For details, see
the test suite and
implementation report.
Changes since the last publication of this document include:
Non-normative insertion of an additional example and some minor editorial
modifications to a few sentences in the specification.
This document has been reviewed by W3C Members, by software developers, and
by other W3C groups and interested parties, and is endorsed by the Director
as a W3C Recommendation. It is a stable document and may be used as
reference material or cited from another document. W3C's role in making the
Recommendation is to draw attention to the specification and to promote its
widespread deployment. This enhances the functionality and interoperability
of the Web.
This document was produced by a group
operating under the
W3C Patent Policy.
W3C maintains a
public list of any patent disclosures
made in connection with the deliverables of
the group; that page also includes
instructions for disclosing a patent. An individual who has actual
knowledge of a patent which the individual believes contains
Essential Claim(s)
must disclose the information in accordance with
section 6 of the W3C Patent Policy.
Credentials are a part of our daily lives; driver's licenses are used to
assert that we are capable of operating a motor vehicle, university degrees
can be used to assert our level of education, and government-issued passports
enable us to travel between countries. These credentials provide
benefits to us when used in the physical world, but their use on the Web
continues to be elusive.
Currently it is difficult to express education qualifications, healthcare
data, financial account details, and other sorts of third-party verified
machine-readable personal information on the Web. The difficulty of expressing
digital credentials on the Web makes it challenging to receive the same
benefits through the Web that physical credentials provide us in the
physical world.
This specification provides a standard way to express credentials on the
Web in a way that is cryptographically secure, privacy respecting, and
machine-verifiable.
For those unfamiliar with the concepts related to
verifiable credentials, the following sections provide an overview of:
The use cases and requirements that informed this specification.
1.1 What is a Verifiable Credential?
이 부분은 비규범적입니다.
In the physical world, a credential might consist of:
Information related to identifying the subject of the credential
(for example, a photo, name, or identification number)
Information related to the issuing authority (for example, a city government,
national agency, or certification body)
Information related to the type of credential this is (for example, a
Dutch passport, an American driving license, or a health insurance card)
Information related to specific attributes or properties being asserted by
the issuing authority about the subject (for example, nationality,
the classes of vehicle entitled to drive, or date of birth)
Evidence related to how the credential was derived
Information related to constraints on the credential (for example, expiration
date, or terms of use).
A verifiable credential can represent all of the same information that a
physical credential represents. The addition of technologies, such as
digital signatures, makes verifiable credentials more tamper-evident and
more trustworthy than their physical counterparts.
Both verifiable credentials and verifiable presentations can be
transmitted rapidly, making them more convenient than their physical
counterparts when trying to establish trust at a distance.
While this specification attempts to improve the ease of expressing digital
credentials, it also attempts to balance this goal with a number of
privacy-preserving goals. The persistence of digital information, and the ease
with which disparate sources of digital data can be collected and correlated,
comprise a privacy concern that the use of verifiable and easily
machine-readable credentials threatens to make worse. This document
outlines and attempts to address a number of these issues in Section
§ 4.4 Privacy Considerations. Examples of how to use this data model
using privacy-enhancing technologies, such as zero-knowledge proofs, are also
provided throughout this document.
1.2 Ecosystem Overview
이 부분은 비규범적입니다.
This section describes the roles of the core actors and the relationships
between them in an ecosystem where verifiable credentials are expected
to be useful. A role is an abstraction that might be implemented in many
different ways. The separation of roles suggests likely interfaces and
protocols for standardization. The following roles are introduced in this
specification:
A role an entity performs by receiving one or more
verifiable credentials, optionally inside a
verifiable presentation, for processing. Example verifiers include
employers, security personnel, and websites.
A role a system might perform by mediating the creation and verification
of identifiers, keys, and other relevant data, such as
verifiable credential schemas, revocation registries, issuer public keys,
and so on, which might be required to use verifiable credentials. Some
configurations might require correlatable identifiers for subjects.
Example verifiable data registries include trusted databases, decentralized
databases, government ID databases, and distributed ledgers. Often
there is more than one type of verifiable data registry utilized in an
ecosystem.
그림 1
The roles and information flows forming the basis for this specification.
Note
그림 1 above provides an example ecosystem in which to ground the
rest of the concepts in this specification. Other ecosystems exist, such as
protected environments or proprietary systems, where
verifiable credentials also provide benefit.
1.3 Use Cases and Requirements
이 부분은 비규범적입니다.
The Verifiable Credentials Use Cases document [VC-USECASES] outlines a number
of key topics that readers might find useful, including:
A more thorough explanation of the
roles
introduced above
The
needs
identified in market verticals, such as education, finance, healthcare, retail,
professional licensing, and government
Common
tasks
performed by the roles in the ecosystem, as well as their associated
requirements
As a result of documenting and analyzing the use cases document, the following
desirable ecosystem characteristics were identified for this specification:
Verifiable credentials represent statements made by an issuer in
a tamper-evident and privacy-respecting manner.
The specification must provide a means for issuers to issue
verifiable credentials that support selective disclosure, without
requiring all conformant software to support that feature.
Verifiable credentials and verifiable presentations have to be
serializable in one or more machine-readable data formats. The process of
serialization and/or de-serialization has to be deterministic, bi-directional,
and lossless. Any serialization of a verifiable credential or
verifiable presentation needs to be transformable to the generic data
model defined in this document in a deterministic process such that the
resulting verifiable credential can be processed in an interoperable
fashion. The serialized form also needs to be able to be generated from the data
model without loss of data or content.
The data model and serialization must be extendable with minimal coordination.
Issuers revoking verifiable credentials should distinguish between
revocation for cryptographic integrity (for example, the signing key is
compromised) versus revocation for a status change (for example, the driver’s
license is suspended).
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, RECOMMENDED, and SHOULD in this document
are to be interpreted as described in
BCP 14
[RFC2119] [RFC8174]
when, and only when, they appear in all capitals, as shown here.
A conforming document is any concrete expression of the data model
that complies with the normative statements in this specification.
Specifically, all relevant normative statements in Sections
§ 4. Basic Concepts, § 5.
Advanced Concepts, and
§ 4.3.2 구문 of this document MUST be enforced. A serialization
format for the conforming document MUST be deterministic, bi-directional,
and lossless as described in Section § 4.3.2 구문.
The conforming documentMAY be transmitted or stored in any such
serialization format.
A conforming processor is any algorithm realized as software and/or
hardware that generates or consumes a conforming document. Conforming
processors MUST produce errors when non-conforming documents are consumed.
This specification makes no normative statements with regard to the
conformance of roles in the ecosystem, such as issuers, holders,
or verifiers, because the conformance of ecosystem roles are highly
application, use case, and market vertical specific.
Digital proof mechanisms, a subset of which are digital signatures, are required
to ensure the protection of a verifiable credential. Having and
validating proofs, which may be dependent on the syntax of the proof
(for example, using the JSON Web Signature of a JSON Web Token for proofing a
key holder), are an essential part of processing a verifiable credential.
At the time of publication, Working Group members had implemented
verifiable credentials using at least three proof mechanisms:
JSON Web Tokens [RFC7519] secured using JSON Web Signatures [RFC7515]
Implementers are advised to note that not all proof mechanisms are standardized
as of the publication date of this specification. The group expects some of
these mechanisms, as well as new ones, to mature independently and become
standardized in time. Given there are multiple valid proof mechanisms, this
specification does not standardize on any single digital signature mechanism.
One of the goals of this specification is to provide a data model that can be
protected by a variety of current and future digital proof mechanisms.
Conformance to this specification does not depend on the details of a particular
proof mechanism; it requires clearly identifying the mechanism a
verifiable credential uses.
This document also contains examples that contain JSON and JSON-LD content.
Some of these examples contain characters that are invalid JSON, such as
inline comments (//) and the use of ellipsis (...)
to denote information that adds little value to the example. Implementers are
cautioned to remove this content if they desire to use the information as
valid JSON or JSON-LD.
2. Terminology
이 부분은 비규범적입니다.
The following terms are used to describe concepts in this specification.
A set of one or more claims made by an issuer. A
verifiable credential is a
tamper-evident credential that has authorship that can be cryptographically
verified. Verifiable credentials can be used to build
verifiable presentations, which can also be cryptographically verified.
The claims in a credential can be about different subjects.
data minimization
The act of limiting the amount of shared data strictly to the minimum
necessary to successfully accomplish a task or goal.
decentralized identifier
A portable URL-based identifier, also known as a DID,
associated with an entity. These identifiers are most often used in a
verifiable credential and are associated with subjects such that a
verifiable credential itself can be easily ported from one
repository to another without the need to reissue the credential.
An example of a DID is did:example:123456abcdef.
decentralized identifier document
Also referred to as a DID document, this is a document
that is accessible using a verifiable data registry and contains
information related to a specific decentralized identifier, such as the
associated repository and public key information.
derived predicate
A verifiable, boolean assertion about the value of another attribute in a
verifiable credential. These are useful in zero-knowledge-proof-style
verifiable presentations because they can limit information disclosure.
For example, if a verifiable credential contains an attribute
for expressing a specific height in centimeters, a derived predicate
might reference the height attribute in the verifiable credential
demonstrating that the issuer attests to a height value meeting the
minimum height requirement, without actually disclosing the specific height
value. For example, the subject is taller than 150 centimeters.
digital signature
A mathematical scheme for demonstrating the authenticity of a digital message.
entity
A thing with distinct and independent existence, such as a person,
organization, or device that performs one or more roles in the ecosystem.
graph
A network of information composed of subjects and their relationship
to other subjects or data.
The means for keeping track of entities across contexts. Digital
identities enable tracking and customization of entity interactions
across digital contexts, typically using identifiers and attributes. Unintended
distribution or use of identity information can compromise privacy. Collection
and use of such information should follow the principle of
data minimization.
identity provider
An identity provider, sometimes abbreviated as IdP, is a system
for creating, maintaining, and managing identity information for
holders, while providing authentication services to
relying party applications within a federation or distributed network.
In this case the holder is always the subject. Even if the
verifiable credentials are bearer credentials, it is assumed the
verifiable credentials remain with the subject, and if they are
not, they were stolen by an attacker. This specification does not use this term
unless comparing or mapping the concepts in this document to other
specifications. This specification decouples the identity provider
concept into two distinct concepts: the issuer and the holder.
Data derived from one or more verifiable credentials, issued by one or
more issuers, that is shared with a specific verifier. A
verifiable presentation
is a tamper-evident presentation encoded in such a way that authorship of the
data can be trusted after a process of cryptographic verification. Certain
types of verifiable presentations might contain data that is synthesized from,
but do not contain, the original verifiable credentials (for example,
zero-knowledge proofs).
A role a system might perform by mediating the creation and verification
of identifiers, keys, and other relevant data, such as
verifiable credential schemas, revocation registries, issuer public keys,
and so on, which might be required to use verifiable credentials. Some
configurations might require correlatable identifiers for subjects. Some
registries, such as ones for UUIDs and public keys, might just act as namespaces
for identifiers.
verification
The evaluation of whether a verifiable credential or verifiable presentation
is an authentic and timely statement of the issuer or presenter, respectively.
This includes checking that: the credential (or presentation) conforms to the specification; the proof method is
satisfied; and, if present, the status check succeeds.
A Uniform Resource Identifier, as defined by [RFC3986].
3. Core Data Model
이 부분은 비규범적입니다.
The following sections outline core data model concepts, such as claims,
credentials, and presentations, which form the foundation of this
specification.
3.1 Claims
이 부분은 비규범적입니다.
A claim is a statement about a subject. A subject is
a thing about which claims can be made. Claims are expressed using
subject-property-value
relationships.
그림 2
The basic structure of a claim.
The data model for claims, illustrated in 그림 2
above, is powerful and can be used to express a large variety of statements. For
example, whether someone graduated from a particular university can be expressed
as shown in 그림 3 below.
그림 3
A basic claim expressing that Pat is an alumni of "Example University".
Individual claims can be merged together to express a graph of
information about a subject. The example shown in
그림 4 below extends the previous claim by
adding the claims that Pat knows Sam and that Sam is employed as a
professor.
그림 4
Multiple claims can be combined to express a graph of information.
To this point, the concepts of a claim and a graph of information
are introduced. To be able to trust claims, more information is
expected to be added to the graph.
3.2 Credentials
이 부분은 비규범적입니다.
A credential is a set of one or more claims made by the same
entity. Credentials might also include an identifier and
metadata to describe properties of the credential, such as the
issuer, the expiry date and time, a representative image, a public key
to use for verification purposes, the revocation mechanism, and so on.
The metadata might be signed by the issuer. A
verifiable credential is a set of tamper-evident claims and
metadata that cryptographically prove who issued it.
그림 5
Basic components of a verifiable credential.
Examples of verifiable credentials include digital employee
identification cards, digital birth certificates, and digital educational
certificates.
Note
Credential identifiers are often used to identify specific instances
of a credential. These identifiers can also be used for correlation. A
holder wanting to minimize correlation is advised to use a selective
disclosure scheme that does not reveal the credential identifier.
그림 5 above shows the basic components of a
verifiable credential, but abstracts the details about how claims
are organized into information graphs, which are then organized into
verifiable credentials. 그림 6 below shows a
more complete depiction of a verifiable credential, which is normally
composed of at least two information graphs. The first graph
expresses the verifiable credential itself, which contains
credential metadata and
claims. The second
graph expresses the
digital proof, which is
usually a digital signature.
그림 6
Information graphs associated with a basic verifiable credential.
Note
It is possible to have a credential, such as a marriage certificate,
containing multiple claims about different subjects that are not
required to be related.
Note
It is possible to have a credential that does not contain any
claims about the entity to which the credential was issued.
For example, a credential that only contains claims about a
specific dog, but is issued to its owner.
3.3 Presentations
이 부분은 비규범적입니다.
Enhancing privacy is a key design feature of this specification. Therefore, it
is important for entities using this technology to be able to express
only the portions of their persona that are appropriate for a given situation.
The expression of a subset of one's persona is called a
verifiable presentation. Examples of different personas include a
person's professional persona, their online gaming persona, their
family persona, or an incognito persona.
The data in a presentation is often about the same subject, but
might have been issued by multiple issuers. The aggregation of this
information typically expresses an aspect of a person, organization, or
entity.
그림 7
Basic components of a verifiable presentation.
그림 7 above shows the components of a
verifiable presentation, but abstracts the details about how
verifiable credentials are organized into information graphs,
which are then organized into verifiable presentations.
그림 8 below shows a more complete depiction of a
verifiable presentation, which is normally composed of at least four
information graphs. The first graph expresses the
verifiable presentation itself, which contains
presentation metadata.
The verifiablePresentation property in the graph refers to
one or more verifiable credentials (each a self-contained graph),
which in turn contains
credential metadata and
claims.
The third graph expresses the
credential graph proof,
which is usually a digital signature. The fourth graph expresses the
presentation graph proof,
which is usually a digital signature.
그림 8
Information graphs associated with a basic verifiable presentation.
Note
It is possible to have a presentation, such as a business persona, which
draws on multiple credentials about different subjects that are
often, but not required to be, related.
To illustrate this lifecycle, we will use the example of redeeming an alumni
discount from a university. In the example below, Pat receives an alumni
verifiable credential from a university, and Pat stores the
verifiable credential in a digital wallet.
{
// set the context, which establishes the special terms we will be using
// such as 'issuer' and 'alumniOf'.
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
// specify the identifier for the credential
"id": "http://example.edu/credentials/1872",
// the credential types, which declare what data to expect in the credential
"type": ["VerifiableCredential", "AlumniCredential"],
// the entity that issued the credential
"issuer": "https://example.edu/issuers/565049",
// when the credential was issued
"issuanceDate": "2010-01-01T19:73:24Z",
// claims about the subjects of the credential
"credentialSubject": {
// identifier for the only subject of the credential
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
// assertion about the only subject of the credential
"alumniOf": {
"id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
"name": [{
"value": "Example University",
"lang": "en"
}, {
"value": "Exemple d'Université",
"lang": "fr"
}]
}
},
// digital proof that makes the credential tamper-evident// see the NOTE at end of this section for more detail
"proof": {
// the cryptographic signature suite that was used to generate the signature
"type": "RsaSignature2018",
// the date the signature was created
"created": "2017-06-18T21:19:10Z",
// purpose of this proof
"proofPurpose": "assertionMethod",
// the identifier of the public key that can verify the signature
"verificationMethod": "https://example.edu/issuers/keys/1",
// the digital signature value
"jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
PAYuNzVBAh4vGHSrQyHUdBBPM"
}
}
Pat then attempts to redeem the alumni discount. The verifier, a ticket
sales system, states that any alumni of "Example University" receives a discount
on season tickets to sporting events. Using a mobile device, Pat starts the
process of purchasing a season ticket. A step in this process requests an alumni
verifiable credential, and this request is routed to Pat's digital wallet.
The digital wallet asks Pat if they would like to provide a previously issued
verifiable credential. Pat selects the alumni
verifiable credential, which is then composed into a
verifiable presentation. The verifiable presentation is sent to
the verifier and verified.
예시 2: A simple example of a verifiable presentation
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"type": "VerifiablePresentation",
// the verifiable credential issued in the previous example
"verifiableCredential": [{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/1872",
"type": ["VerifiableCredential", "AlumniCredential"],
"issuer": "https://example.edu/issuers/565049",
"issuanceDate": "2010-01-01T19:73:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"alumniOf": {
"id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
"name": [{
"value": "Example University",
"lang": "en"
}, {
"value": "Exemple d'Université",
"lang": "fr"
}]
}
},
"proof": {
"type": "RsaSignature2018",
"created": "2017-06-18T21:19:10Z",
"proofPurpose": "assertionMethod",
"verificationMethod": "https://example.edu/issuers/keys/1",
"jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
PAYuNzVBAh4vGHSrQyHUdBBPM"
}
}],
// digital signature by Pat on the presentation
// protects against replay attacks
"proof": {
"type": "RsaSignature2018",
"created": "2018-09-14T21:19:10Z",
"proofPurpose": "authentication",
"verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1",
// 'challenge' and 'domain' protect against replay attacks
"challenge": "1f44d55f-f161-4938-a659-f8026467f126",
"domain": "4jt78h47fh47",
"jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..kTCYt5
XsITJX1CxPCT8yAV-TVIw5WEuts01mq-pQy7UJiN5mgREEMGlv50aqzpqh4Qq_PbChOMqs
LfRoPsnsgxD-WUcX16dUOqV0G_zS245-kronKb78cPktb3rk-BuQy72IFLN25DYuNzVBAh
4vGHSrQyHUGlcTwLtjPAnKb78"
}
}
Note
Implementers that are interested in understanding more about the
proof mechanism used above can learn more in
Section § 프루프들 (시그니쳐들) and by reading the
following specifications: Linked Data Proofs [LD-PROOFS], Linked Data
Signatures [LD-SIGNATURES], 2018 RSA Signature Suite [LDS-RSA2018], and
JSON Web Signature (JWS) Unencoded Payload Option [RFC7797]. A list
of proof mechanisms is available in the Verifiable Credentials
Extension Registry [VC-EXTENSION-REGISTRY].
4. Basic Concepts
This section introduces some basic concepts for the specification, in
preparation for Section § 5.
Advanced Concepts later in the
document.
4.1 Contexts
When two software systems need to exchange data, they need to use terminology
that both systems understand. As an analogy, consider how two people
communicate. Both people must use the same language and the words they use must
mean the same thing to each other. This might be referred to as
the context of a conversation.
In JSON-LD, the @contextproperty can also be used to
communicate other details, such as datatype information, language information,
transformation rules, and so on, which are beyond the needs of this
specification, but might be useful in the future or to related work. For more
information, see
Section 3.1: The Context
of the [JSON-LD] specification.
The value of the @contextpropertyMUST be an ordered set
where the first item is a URI with the value
https://www.w3.org/2018/credentials/v1. For reference, a copy of
the base context is provided in Appendix § A. Base Context.
Subsequent items in the array MUST express context information and be composed
of any combination of URIs or objects. It is RECOMMENDED that each
URI in the @context be one which, if dereferenced, results
in a document containing machine-readable information about the
@context.
Note
Though this specification requires that a @contextproperty
be present, it is not required that the value of the @contextproperty be processed using JSON-LD. This is to support processing using
plain JSON libraries, such as those that might be used when the
verifiable credential is encoded as a JWT. All libraries or processors
MUST ensure that the order of the values in the @contextproperty is what is expected for the specific application. Libraries or
processors that support JSON-LD can process the @contextproperty using full JSON-LD processing as expected.
The example above uses the base context URI
(https://www.w3.org/2018/credentials/v1) to establish that the
conversation is about a verifiable credential. The second URI
(https://www.w3.org/2018/credentials/examples/v1) establishes that
the conversation is about examples.
Note
This document uses the example context URI
(https://www.w3.org/2018/credentials/examples/v1) for the purpose
of demonstrating examples. Implementations are expected to not use this
URI for any other purpose, such as in pilot or production systems.
The data available at https://www.w3.org/2018/credentials/v1 is a
static document that is never updated and SHOULD be downloaded and cached. The
associated human-readable vocabulary document for the Verifiable Credentials
Data Model is available at
https://www.w3.org/2018/credentials.
This concept is further expanded on in Section § 확장성.
4.2 식별자
사람, 제품, 또는 조직과 같은 특정한 것에 대해 표현할때,
다른 사람들이 동일한 것을 표현할 수 있도록 식별자를 사용하는 것이 유용하다.
이 규격에서는 이러한 식별자들에 대한 선택적 id 속성을 정의한다.
id속성은 사람, 제품 또는 조직과 같은 객체를 명확하게 참조하기 위한 것이다.
id속성을 사용하면
검증가능한 크리덴셜을 통해 특정한 사물을 표현할 수 있게 된다.
개발자들은 익명성이 요구되는 시나리오에서 식별자가 유해할 수 있다는 것을 기억해야 한다.
그러한 시나리오를 고려할 때 § 4.4.3 식별자 기반 상관관계 부분을 주의깊게 읽을 것을 권장한다.
프라이버시 문제를 만들어 내는 다른 유형의 연관메커니즘문서도
§ 4.4 Privacy Considerations에서 다룬다.
프라이버시가 중요한 고려사항인 경우 id속성은 생략 될 수 있다.
id
id속성 값은 반드시 단일 URI여야 한다.
역참조되는 경우 URI는 id에 대한
기계판독가능정보를 포함한 문서를 생성하는 것이 권장된다.
type속성의 값은 반드시 맵핑된(@context 속성의 해석을 통해),
하나 또는 이상의 URIs다.
만약 복수의 URI들이 제공되었다면, URIs는 순서가 없는 집합으로 해석해야 한다.
개발편의를 위해 문법적 편의성을 반드시 사용해야 한다.
이러한 편의성에는 JSON-LD 용어가 포함될 수 있다.
type의 각 URI가 역참조되는 경우
type에 대한 기계판독가능정보가 포함된 문서를 생성하는 것이 권장된다.
VerifiableCredential and, optionally, a more specific
verifiable credentialtype. For example, "type": ["VerifiableCredential", "UniversityDegreeCredential"]
VerifiableCredential and, optionally, a more specific
verifiable credentialtype. For example, "type": ["VerifiableCredential", "UniversityDegreeCredential"]
VerifiablePresentation and, optionally, a more specific
verifiable presentationtype. For example, "type": ["VerifiablePresentation", "CredentialManagerPresentation"]
VerifiablePresentation and, optionally, a more specific
verifiable presentationtype. For example, "type": ["VerifiablePresentation", "CredentialManagerPresentation"]
A valid evidence type. For example, "type": "DocumentVerification2018"
Note
검증가능한 크리덴셜 데이터 모델의 타입시스템은 [JSON-LD]와 동일하며
섹션 5.4:
Specifying the Type 그리고 섹션 8: JSON-LD
Grammar에 자세히 설명되어 있다. JSON-LD 컨텍스트를 사용할 때 (
§ 확장성 참조),
이 규격의 @type 키워드를 다른 이름인 type으로 바꾸면
JSON-LD 문서의 이해가 쉬워질 것이다.
애플리케이션 개발자와 문서 작성자는 JSON-LD 타입 시스템의 세부사항을 이해할 필요는 없지만,
상호운용 가능한 확장성을 지원하려는 이 규격의 구현자들은 그 내용을 이해해야 한다.
모든 크리덴셜, 프레젠테이션, 그리고 캡슐화된 객채들은 추가정보를 처리할 수 있도록,
더욱 제한된 타입들(예를 들어 UniversityDegreeCredential과 같은)을
반드시 명시하거나 연관시켜야 한다.
이 규격에 정의된 캡슐화된 객체
(예를 들어 credentialSubject객체와 관련되거나 깊이 중첩된 객체들)들을 처리할 때,
소프트웨어 시스템은 객체를 캡슐화할때 사용된 상위 계층의타입 정보를 사용해야 한다.
구체적으로 크리덴셜과 같은 캡슐화된 객체들은 연관된 객체 타입을 전달하여,
검증자가 캡슐화 객체의 타입에 기초하여 관련 객체의 내용을 신속하게 파악할 수 있어야한다.
예를 들어, UniversityDegreeCredential과 같은 type의 크리덴셜 객체는
다음 항목을 위한 식별자가 credentialSubject 속성에 포함되어 있다는 것을
검증자에게 전송한다:
The value of the credentialSubjectproperty is defined as
credentialSubject속성의 값은 검증가능한 크리덴셜의 주체와
각각 관련된 하나 이상의 특성을 포함하는
객체 세트로 정의된다. § 4.2 식별자에 설명 된대로 각 객체에는 id가 포함될 수도 있다.
issuer속성 값은 무조건 URI이거나 id속성을 포함하는 객체여야한다.
issuer 또는 해당 id의 URI는 역 참조 된 경우
크리덴셜에 표시된 정보를 검증하는 데 사용할 수 있는
issuer에 대한 기계판독 가능한 정보를 포함하는 문서를 생성하는 URI 여야 한다.
issuer특성값은 JWK (예를 들어, "https://example.com/keys/foo.jwk")
또는 a DID (예를 들어, "did:example:abfe13f712120431c276e12ecab")이 될 수 있다.
발급 날짜
이 규격은 크리덴셜이 유효한 날짜 및 시간을 표현하기 위한 issuanceDate속성을 정의한다.
issuanceDate
크리덴셜은 무조건 issuanceDate속성을 가져야 한다.
issuanceDate속성의 값은
크리덴셜이 유효한 날짜와 시간을 나타내는 [RFC3339] 결합 날짜 및 시간
문자열의 문자열 값이어야하며 이는 미래의 날짜와 시간 일 수 있습니다. 이 값은 credentialSubject특성과 연관된 정보가 유효 해지는 가장 빠른 시점을 나타냅니다.
이 스펙의 다음 버전은 validFrom속성을 추가하고
새로운 issued 된 속성을 위해 issuanceDate속성을
더 이상 사용하지 않을 것으로 예상된다. 두 속성의 값 범위는 [RFC3339] 결합 날짜 및 시간 문자열로 유지
될 것으로 예상한다. 구현자는 validFrom 및 issued속성을 예약하고
다른 목적으로 사용하지 않는 것이 좋다.
이 규격은 두가지 종류의 메커니즘을 식별한다: 외부 증명과 내장된 증명.
외부 프루프은 § JSON Web Token섹션에 자세히
설명되어 있는 JSON 웹 토큰과 같은 데이터 모델의 표현을 감싸는 것이다.내장 된 프루프는 § Linked Data Proofs
섹션에 자세히 설명된 linked data signature과 같은 데이터에 증명이 포함되는 메커니즘이다.
변조를 감지하고 크리덴셜 또는 프레젠테이션의 소유권을 확인하는 데 사용할 수 있는 하나
이상의 암호화 프루프이다. 내장 된 프루프에 사용되는 특정 방법은 무조건 type속성을 사용하여 포함해야한다.
수학적 증명에 사용되는 방법은 표현 언어와 사용 된 기술에 따라 다르므로 proof속성의 값으로 예상되는
이름-값 쌍 세트는 그에 따라 달라진다. 예를 들어, 프루프 메커니즘에 디지털 서명이 사용되는 경우 proof속성에는 서명, 서명 엔터티에 대한 참조 및 서명 날짜 표시가 포함 된 이름-값 쌍이 있어야한다. 아래 예는 RSA
디지털 서명을 사용한다.
§ 1.4 Conformance에서 논의 된 바와 같이, 여러 가지 가능한 증명 메커니즘이 있으며,
이 사양은 검증가능한 크리덴셜과 함께 사용하기위한 단일 증명 메커니즘을 표준화하거나 권장하지 않는다.
proof 메커니즘에 대한 자세한 내용은 다음 사양을 참조하시오. Linked Data Proofs [LD-PROOFS],
Linked Data Signatures [LD-SIGNATURES], 2018 RSA Signature Suite [LDS-RSA2018] 및 JSON Web Signature(JWS)
Unencoded Payload Option [RFC7797]. 프루프메커니즘 목록은 Verifiable Credentials Extension Registry
[VC-EXTENSION-REGISTRY]에서 찾을 수 있다.
상태 체계에 대한 데이터 모델, 형식 및 프로토콜 정의는 이 사양에서 다루지 않는다.
a>검증가능한 크리덴셜 상태 확인의 구현을 원하는 개발자가 사용할 수 있는
상태 스키마를 포함하는 Verifiable Credentials Extension Registry [VC-EXTENSION-REGISTRY]가 존재한다.
일부 영지식 증명 체계는 보유자가 검증가능한 크리덴셜 자체를 밝히지 않고
검증가능한 크리덴셜으로부터 클레임들을 보유하고 있음을 간접적으로 입증 할 수있도록 해준다.
이러한 방식에서, 검증가능한 크리덴셜의 클레임들은
제시된 값을 도출한는데 사용될 수 있으며,
이는 검증자가 발급자를 신뢰하는 경우, 암호학적으로 그 값을 보장할 수 있다.
예를 들어, 생년월일클레임이 포함된 검증가능한 크리덴셜을 사용하여
15세 이상의 제시된 값을 암호학적으로 검증가능한방식으로 도출할 수 있다.
즉, 검증자는 발행자를 신뢰하는 경우 파생된 값을 계속 신회할 수 있다.
영지식 증명을 사용하는 선택적 공개 체계에서는 이 모델에 포현된 클레임들을 사용하여
해당 클레임에 대한 추가적인 주장들을 만들어낼 수 있다.
예를 들어, 어떤 주체의 생년월일을 나타내는 클레임은
해당 주체의 나이가 주어진 범위 안에 있음을 증명하는데 사용될 수 있고,
따라서 대상이 나이 관련 할인을 받을 수 있음을 실제로 주체의 생년월일을 밝히지 않고 증명할 수 있다.
보유자는 원하는 검증가능한 프레젠테이션에 적용할 수 있는 방식으로 클레임을 사용할 수 있는 유연성을 가지게 된다.
그림 9
Pat의 생년월일이 2010-01-01T19:23:24Z라는걸 나타내는 기본적인 클레임. 시간 인코딩은 스키마에따라 결정된다.
The order of the actions above is not fixed, and some actions might be taken
more than once. Such action-recurrence might be immediate or at any later
point.
The most comon sequence of actions is envisioned to be:
This specification does not define any protocol for transfering
verifiable credentials or verifiable presentations, but assuming
other specifications do specify how they are transferred between entities, then
this Verifiable Credential Data Model is directly applicable.
신원 제공자와 신뢰 당사자간의 신뢰 결합을 제거함으로써 더 유연하고 동적인 신뢰 모델이 생성되고,
그로 인해 시장 경쟁이 치열해지고 고객 선택의 폭이 증가한다.
워킹 그룹에서 연구한 이 신뢰 모델이 어떻게 다양한 위협 모델과 상호작용하는가에 대한
더 많은 정보는 검증가능한 크리덴셜 유즈케이스 문서 참조. [VC-USECASES]
Note
이 규격에서 설명하고 있는 데이터 모델은 전통적인 인증 기관의 신뢰 모델에서 제공하는 것과 같은
전이 가능한(transitive) 신뢰 모델을 내포하지는 않는다.
검증가능한 크리덴셜 데이터 모델에서 검증자는 발급자를 직접 믿을 수도 있고 믿지 않을 수도 있다.
검증가능한 크리덴셜 데이터 모델을 이용하는 전이 가능한 신뢰 모델을 구축하는 것이 가능함에도 불구하고,
구현자는 인증 기관 시스템에서 채택했던 것과 마찬가지로
광범위 위임 신뢰(broadly delegating trust)에서 소개된
보안 취약점에 대해 공부해야 한다.
확장성
검증가능한 크리덴셜 데이터 모델의 목표 중 하나는 비허가형 방식의 혁신을 활성화하는데 있다.
이러한 목표를 달성하기 위하여, 이 데이터 모델은 수많은 다른 방법으로 확장가능할 필요가 있다.
이 데이터 모델에 요구되는 것은:
[LINKED-DATA]의 사용을 통하여, 중앙화된 시스템 없이도,
데이터 모델 안에 있는 정보를 기술하는데 사용되는 기계 판독 가능 어휘 목록을 확장한다.
연결 데이터 프루프(Linked Data Proofs, [LD-PROOFS]) 및 연결 데이터 서명(Linked Data Signatures, [LD-SIGNATURES])
그리고 다양한 서명 제품군(signature suites)의 사용을 통해 여러 유형의 암호학적 프루프 형식을 지원한다.
소프트웨어 개발자 및 웹 페이지 제작자들에게 자주 쓰이고,
[JSON-LD]의 사용을 통해 활성화 된 데이터 형식에서 상술한 모든 확장 메커니즘을 제공한다.
데이터 모델링에 대한 이러한 접근 방식은 종종 “열린 세계 가정 (open world assumption)"이라고하며,
이는 누구나 다른 누군가에 대해 말할 수 있다는 것을 의미한다.
이러한 접근 방식이 간단하고 예측 가능한 소프트웨어 시스템을 구축하는 것과 충돌하는 것처럼 보일 수 있음에도 불구하고,
프로그램의 정확성과 확장성 간에 균형을 맞추는 것은 폐쇄형 소프트웨어 시스템보다 열린 세계 가정에서 항상 더 도전적인 과제이다.
이 섹션의 나머지 부분에서는 여러 예제들을 통해 확장성과 프로그램 정확성을 모두 달성하는 방법에 대해 설명한다.
이 JSON-LD 컨텍스트가 생성된 이후에,
그 개발자는 생성한 것을 어딘가에 발행해서 이 검증가능한 크리덴셜을 처리할 검증자가 접근할 수 있도록 만든다.
위의 JSON-LD 컨텍스트가 https://example.com/contexts/mycontext.jsonld에 발행되었다고 가정하면,
우리는 이 검증가능한 크리덴셜에 컨텍스트를 포함하고
새로운 속성 및 크리덴셜타입을 추가함으로써 이 예제를 확장할 수 있게 된다.
이 예제는 검증가능한 크리덴셜 데이터 모델이 비허가형이고 탈중화된 방식으로 확장되는 것을 보여준다.
이 메커니즘은 또한, 이런 방식으로 생성된 검증가능한 크리덴셜이 네임스페이스 충돌 및 의미 중의성을 방지하기 위한
메커니즘을 제공한다는 것을 확실히 보여준다.
이러한 동적 확장성 모델은 구현 부담을 분명히 증가시킨다.
이런 시스템용으로 작성된 소프트웨어는,
응용 프로그램의 위험 프로파일을 기반으로 확장된 검증가능 크리덴셜을 받아들일지 여부를 결정해야한다.
어떤 응용 프로그램은 특정 확장을 허용하면서도 높은 보안성이 요구되는 환경에서는
모든 확장을 허용하지 않을 수 있다.
이러한 결정은 응용 프로그램 개발자에게 달려 있으며 이 규격에서 구체적으로 다루는 영역이 아니다.
개발자는 확장된 JSON-LD 컨텍스트의 가용성을 높이기 위해 노력해야 한다.
컨텍스트를 가져올 수 없는 구현물은 오류를 발생 시킬 것이다.
컨텍스트를 위한 내용 지정 URL들의 사용, 컨텍스트 문서와 구현물의 번들링,
또는 컨텍스트의 적극적인 캐싱 활성화를 포함하여 확장 JSON-LD 컨텍스트를 보장하는 전략은 언제나 유효하다.
Implementers are advised to pay close attention to the extension points in this
specification, such as in Sections § 프루프들 (시그니쳐들),
§ 상태, § 5.4 데이터 스키마 ,§ 5.5 리프레싱,
§ 이용약관, and § 증거. While this
specification does not define concrete implementations for those extension
구현자는 § 프루프들 (시그니쳐들),
§ 상태, § 5.4 데이터 스키마 , § 5.5 리프레싱,
§ 이용약관, § 증거
에서
설명하고 있는 확장 기능에 대단히 주의를 기울여야 한다.
비록 이 규격이 확장 기능과 관련한 구체적인 구현에 대해 정의하고 있진 않지만,
검증가능한 크리덴셜 확장 레지스트리[VC-EXTENSION-REGISTRY]는
개발자가 활용할 수 있도록 비공식적인 확장 기능 목록을 제공한다.
Semantic Interoperability
This specification ensures that "plain" JSON and JSON-LD syntaxes are
semantically compatible without requiring JSON implementations to use a JSON-LD
processor. To achieve this, the specification imposes the following additional
requirements on both syntaxes:
JSON-based processors MUST process the @context key, ensuring the
expected values exist in the expected order for the credential type being
processed. The order is important because keys used in a credential,
which are defined using the values associated with @context, are
defined using a "first defined wins" mechanism and changing the order might
result in a different key definition "winning".
JSON-LD-based processors MUST produce an error when a JSON-LD context redefines
any term in the
active context.
The only way to change the definition of existing terms is to introduce a new
term that clears the active context within the scope of that new term. Authors
that are interested in this feature should read about the
@protected feature in the JSON-LD 1.1 specification.
A human-readable document describing the expected order of values for the
@contextproperty is expected to be published by any
implementer seeking interoperability. A machine-readable description
(that is, a normal JSON-LD Context document) is expected to be published
at the URL specified in the @contextproperty by
JSON-LD implementers seeking interoperability.
The requirements above guarantee semantic interoperability between JSON and
JSON-LD for terms defined by the @context mechanism. While JSON-LD
processors will use the specific mechanism provided and can verify that all
terms are correctly specified, JSON-based processors implicitly accept the same
set of terms without testing that they are correct. In other words, the context
in which the data exchange happens is explicitly stated for both JSON and
JSON-LD by using the same mechanism. With respect to JSON-based processors, this
is achieved in a lightweight manner, without having to use JSON-LD processing
libraries.
Data Schemas
Data schemas are useful when enforcing a specific structure on a given
collection of data. There are at least two types of data schemas that this
specification considers:
Data verification schemas, which are used to verify that the structure
and contents of a verifiable credential conform to a published schema.
Data encoding schemas, which are used to map the contents of a
verifiable credential to an alternative representation format, such as a
binary format used in a zero-knowledge proof.
It is important to understand that data schemas serve a different purpose from
the @context property, which neither enforces data structure or
data syntax, nor enables the definition of arbitrary encodings to alternate
representation formats.
This specification defines the following property for the expression of a
data schema:
credentialSchema
The value of the credentialSchemapropertyMUST be one or
more data schemas that provide verifiers with enough information to
determine if the provided data conforms to the provided schema. Each
credentialSchemaMUST specify its type (for example,
JsonSchemaValidator2018), and an idproperty
that MUST be a URI identifying the schema file. The precise contents of
each data schema is determined by the specific type definition.
Note
The credentialSchemaproperty provides an opportunity to
annotate type definitions or lock them to specific versions of the vocabulary.
Authors of verifiable credentials can include a static version of their
vocabulary using credentialSchema that is locked to some content
integrity protection mechanism. The credentialSchemaproperty also makes it possible to perform syntactic checking on the
credential and to use verification mechanisms such as JSON Schema
[JSON-SCHEMA-2018] validation.
예시 18: Usage of the credentialSchema property to perform JSON schema validation
For information about linkages to JSON Schema [JSON-SCHEMA-2018] or other
optional verification mechanisms, see the Verifiable Credentials
Implementation Guidelines [VC-IMP-GUIDE] document.
Data schemas can also be used to specify mappings to other binary formats, such
as those used to perform zero-knowledge proofs. For more information on using
the credentialSchemaproperty with zero-knowledge proofs,
see Section § 영지식 증명.
예시 19: Usage of the credentialSchema property to perform zero-knowledge validation
In the example above, the issuer is specifying a
credentialSchema pointing to a zero-knowledge packed binary data
format that is capable of transforming the input data into a format, which can
then be used by a verifier to determine if the proof provided with the
verifiable credential is valid.
Refreshing
It is useful for systems to enable the manual or automatic refresh of an
expired verifiable credential. For more information about expired
verifiable credentials, see Section § 만료. This
specification defines a refreshServiceproperty, which
enables an issuer to include a link to a refresh service.
The refresh service is only expected to be used when either the
credential has expired or the issuer does not publish
credential status information. Issuers are advised not to put the
refreshServiceproperty in a verifiable credential
that does not contain public information or whose refresh service is not
protected in some way.
The value of the refreshServicepropertyMUST be one or
more refresh services that provides enough information to the recipient's
software such that the recipient can refresh the verifiable credential.
Each refreshService value MUST specify its type (for
example, ManualRefreshService2018) and its id, which
is the URL of the service. The precise content of each refresh service is
determined by the specific refreshServicetype definition.
예시 20: Usage of the refreshService property by an issuer
In the example above, the issuer specifies a manual
refreshService that can be used by directing the holder or
the verifier to https://example.edu/refresh/3732.
termsOfUse속성의 값은 무조건 작성자가 크리덴셜 또는
프레젠테이션을 발행 한 하나 이상의 이용 약관 정책을 지정해야만 한다.
수령자 (보유자 또는 검증자)가 지정된 이용 약관을 준수하지 않을 경우,
책임을 지고 명시된 이용 약관을 위반할 경우 법적 책임을 질 수 있다.
각 termsOfUse 값은 타입을 지정해야 하고
(예: IssuerPolicy), 인스턴스 id를 지정할 수 있다.
각 이용 약관의 정확한 내용은 특정 code>termsOfUse 타입 정의에 의해
결정된다.
위의 예에서, 주체인 보유자(assigner, 양도자)는
검증자(assignee, 양수자, https://wineonline.example.org)가
제 3자 서비스를 사용하여 보유자 또는 주체의 상관관계를 표현하기 위해
제공된 정보를 사용하는 것을 금지하는 사용 기간을 명시한다.
검증자가 상관관계를 위해 제 3자 서비스를 사용하는 경우,
보유자는 프리젠테이션을 작성하는 조건을 위반한다.
이 기능은 정부에서 발행한 검증가능한 크리덴셜에 의해 사용되어 전자 지갑이
시민들의 민감한 데이터를 예기치 않게 사용되는 것을 막기 위하여 유사한 정부 기관으로의
사용을 제한하도록 지시한다. 유사하게 민간 산업에서 발행한
검증가능한 크리덴셜은 조직, 부서 내 또는 업무 시간동안 사용을 제한할
것으로 예상된다. 구현자는 검증가능한 크리덴셜 구현 지침 [VC-IMP-GUIDE] 문서의
적합한 장에서 빠르게 발전하는 기능에 대하여 자세히 읽어야 한다.
evidence속성의 값은 무조건 검증자가 발급자에
의해 수집한 증거가 크리덴셜에 의존하기 위한 신뢰 요구 사항을 충족하는지 여부를
판단할 수 있는 충분한 정보를 제공하는 하나 이상의 증거 체계이어야만 한다.
각 증거 체계는 타입별로 식별된다.
id속성은 선택 사항이지만 존재한다면, 이 증거 인스턴스에 대한
추가 정보를 찾을 수 있는 URL을 포함해야 한다. 각 증거 체계의 정확한 내용은 특정
evidence타입 정의에 의해 결정된다.
Note
명세서에서 크리덴셜 및 크리덴셜이 아닌 데이터에 대한 첨부 및 참조를 지원하는
방법에 대한 자세한 내용은 검증가능한 크리덴셜 구현 지침 [VC-IMP-GUIDE] 문서를 참조.
evidence속성은 proof속성에 대하여
서로 다른 보완 정보를 제공한다. evidence속성은
검증가능한 크리덴셜의 무결성과 관련된 문서 증거와 같은 지원 정보를 표현하는 데
사용된다. 반면에 proof속성은 발급자의 진위 및
검증가능한 크리덴셜의 무결성과 관련된 기계-검증가능한 수학적 증명을
표현하는 데 사용된다. proof속성에 대한 자세한 내용은
을 참조.
검증가능한 크리덴셜을 발급 받고 나면,
추가적인 발급자의 관여 없이도 발급자가 아닌 검증자의 데이터 스키마 형식에 따라
파생된 검증가능한 크리덴셜을 생성할 수 있는 기능.
이를 통해 보유자가 발급 받은 검증가능한 크리덴셜을 사용함에 있어 유연성이 크게 향상된다.
이 규격은 영지식 증명 메커니즘을 지원하는 데이터 모델을 설명한다.
아래 예는 데이터 모델을 사용하여 영지식 검증가능한 크리덴셜을 발급, 제시 및 검증 하는 방법을 보여준다.
영지식 검증가능한 크리덴셜을 사용하려면
발급자는 반드시 보유자가 프라이버시 강화 방식으로 검증자에게 정보 제시가 가능하도록
검증가능한 크리덴셜을 발급해야 한다.
이는 보유자가 서명된 값을 밝히지 않거나 선택된 특정 값만 밝힐 때에도
발급자 서명의 유효성을 입증할 수 있음을 의미한다.
표준 관행은 서명 자체를 밝히지 않고, 서명에 대한 지식을 증명함으로써 그렇게 하는 것이다.
검증가능한 크리덴셜을 영지식 증명 시스템에서 사용할 때 두 가지 요구 사항이 있다.
검증가능한 크리덴셜은 반드시 다음을 포함해야 한다.
credentialSchema속성을 사용한 크리덴셜의 정의.
모든 당사자가 다양한 영지식 암호화 작업을 수행하는 데 사용할 수 있다.
크리덴셜에 식별자가 없는 경우 content-addressed 식별자를 사용하여 이의를
제기한 크리덴셜을 식별할 수 있다. 유사하게 content-addressed 식별자는 개별
요구사항을 고유하게 식별하는데 사용될 수 있다.
Note
본 연구 영역은 빠르게 발전하고 있으며, 다른 크리덴셜의 정확성에 대해 이의를
제기하는 크리덴셜을 발행하는데 관심이 있는 구현자는 검증가능한 크리덴셜
구현 지침 [VC-IMP-GUIDE] 문서에서 분쟁과 관련된 부분을 읽어야 한다.
승인
이 부분은 비규범적입니다.
검증가능한 크리덴셜은 주체에 대한 신뢰할 수 있는 신원증명의 수단으로 만들어졌다.
역할 기반 접근 제어(Role Based Access Controls, RBACs)와 속성 기반 접근 제어(Attribute Based Access Controls, ABACs)는
주체가 자원에 접근하는 것을
승인하는 수단으로써 이 신원인증에 의존하는 것으로 인식되지만, 이 사양은 RBAC
또는 ABAC를 위한 완전한 해결책을 제공하지는 않는다. 승인의 경우 승인 프레임워크 없이
본 사양을 사용하는 것은 적절치 않다.
워킹 그룹은 본 규격의 작성과정에서 인증의 사용 사례를 고려하였으며, 본 규격 위에
구축된 구조적 계층으로서의 작업을 추구하고 있다.
4.3.2 구문
§ 3. Core Data Model, § 4. Basic Concepts
그리고 § 5.
Advanced Concepts에서 설명한 데이터 모델은 검증가능한 크리덴셜
또는 검증가능한 프레젠테이션의 규범적 구조적 표현이다. 모든 직렬화는
특정 형식의 데이터 모델의 표현이다. 본 섹션에서는 데이터 모델이 JSON-LD와 일반 JSON에서
실현되는 방식을 명시한다. 비록 이 두 구문에서만 구문적 매핑이 제공되지만, 데이터 모델을
표현할 수 있는 기타 데이터 표현 구문(XML, YAML 또는 CBOR)도 사용할 수 있다. 검증과 확인
필요사항이 데이터 모델의 관점에서 정의되므로, 모든 직렬화 구문은 결정적으로 처리, 검증
또는 비교를 위한 데이터 모델로 변환되어야 한다. 본 사양은 어떠한 특정 직렬화 형식을
지원하기 위한 요구사항을 만들지 않는다.
본 사양에서 속성 값의 예상되는 아리티 및 그러한 값을 가지는 결과 데이터 타입은 속성에
따라 변동될 수 있다. 만약 존재하는 경우, 다음과 같은 속성들은 단일 값으로 표현된다.
여기 나열된 변환은 잠재적으로 양립할 수 없는 해석을 가지고 있으므로, 데이터 모델의
결정론적 변환을 제공할 수 있으려면 추가적인 JSON 형식의 프로파일링이 필요하다.
JSON-LD
[JSON-LD]는 연결된 데이터를
직렬화하기 위해 사용되는 JSON기반의 형식이다. 해당 구문은
이미 JSON을 사용하는 것으로 배포된 시스템에 쉽게 통합할 수 있도록 설계되었으며, JSON에서
[JSON-LD]로 부드럽게 업그레이드 할 수 있는 길을 제공한다. 이는 주로 웹 기반 프로그래밍
환경에서 연결된 데이터를 사용하고, 상호 운용 가능한 웹 서비스를 구축하며, JSON 기반
저장소 엔진에서 연결된 데이터를 저장하는 방식으로 사용한다.
[JSON-LD]는 본 사양에서 설명한 데이터 모델을 확장할 때 유용하다. 데이터 모델의
인스턴스는 @context속성의 추가를 통해, JSON(섹션 § JSON)으로 인코딩되는 방식과 동일하게
[JSON-LD]로 인코딩된다. JSON-LD 컨텍스트는
[JSON-LD] 사양에서 상세하게 설명되어 있고,
그것의 사용은 섹션 § 확장성에서 상술하고 있다.
관용적 JSON에서의 검증가능한 크리덴셜에 대한 임의의 정보를 표현하기 위해 다수의
컨텍스트가 사용되거나 결합될 수 있다. https://www.w3.org/2018/credentials/v1
에서 확인할 수 있는 JSON-LD 컨텍스트는
고정 문서로서 절대 업데이트 되지 않는다.
따라서 클라이언트 사이드에 캐시하거나 다운로드 할 수 있다. 검증가능한 크리덴셜 데이터 모델에
대한 연계된 용어 문서는 https://www.w3.org/2018/credentials에서 확인할 수 있다.
신택틱 슈거(Syntactic Sugar)
일반적으로, 본 문서에서 설명하고있는 데이터 모델 및 구문은 개발자가 사례를 복사,
붙여넣기 함으로써 자신의 소프트웨어 시스템에 검증가능한 크리덴셜을 포함할 수 있도록 설계되었다.
이러한 접근의 디자인 목표는 이기종 소프트웨어 시스템 간 글로벌 상호 운용성을 보장하는 동시에
진입장벽을 낮추는 것이다.
본 섹션에서는 대부분의 개발자가 눈치채지 못할 수 있지만
구현하는 사람에게는 관심이 있을 접근방식들에 대해 설명한다.
[JSON-LD]에서 가장 주목할만한 신택틱 슈거(Syntatic Sugars)는 아래와 같다.
@id와 @type 키워드는
각각 id와 type으로 구분되어,
개발자가 이 규격을 관용적 JSON으로 사용할 수 있도록 한다.
정수, 날짜, 측정단위, URL과 같은 데이터 타입은 자동으로 입력되어
그것을 필요로 하는 사용 사례(Use Case)를 위한 강력한 타입 보장을 제공한다.
verifiableCredential과 proof속성은
그래프 컨테이너(Graph Containers)로 처리된다.
이는 다른 개체가 주장하는 데이터 집합을 분리하는데 사용되는 메커니즘이다.
이것은 각 발행자가 제공한 데이터 그래프와 각 그래프에 대한 유래를 보장하기 위해
검증가능한 크리덴셜을 제시하는 보유자가 제공하는 정보 간의
적절한 암호학적 구분을 보장한다.
[JSON-LD] 1.1의 @protected 속성 기능은
본 규격에서 정의한 용어를 재정의할 수 없도록 하는데 사용된다.
이는 동일한 @context 선언이
검증가능한 크리덴셜 또는 검증가능한 프레젠테이션의 상단에서 이루어지는 한,
[JSON-LD] 프로세서의 사용 여부와 상관없이
사용자가 이해한 모든 용어에 대한 상호운용성을 보장한다는 의미이다.
Proof Formats
The data model described in this specification is designed to be proof format
agnostic. This specification does not normatively require any particular digital
proof or signature format. While the data model is the canonical representation
of a verifiable credential or verifiable presentation, the
proofing mechanisms for these are often tied to the syntax used in the
transmission of the document between parties. As such, each proofing mechanism
has to specify whether the validation of the proof is calculated against the
state of the document as transmitted, against the transformed data model, or
against another form. At the time of publication, at least two proof formats
are being actively utilized by implementers and the Working Group felt
that documenting what these proof formats are and how they are being used would
be beneficial to implementers. The sections detailing the current proof formats
being actively utilized to issue verifiable credentials are:
JSON Web Token (JWT) [RFC7519]은 여전히 두 당사자 간에 전달되는 클레임을 표현하기 위해
널리 사용되는 수단이다.JWT에 대한 검증 가능한 크리덴셜 데이터 모델을 제공함으로써
기존 시스템과 라이브러리가 섹션 § 1.2 Ecosystem Overview에 설명된 생태계에 참여할 수 있다.
JWT는 일련의 클레임 JSON Web Signature (JWS) [RFC7515] 또는 JWE [RFC7516]에
포함된 JSON 개체로 인코딩한다. 이 규격에서 JWE의 사용은 범위를 벗어나므로 다루지 않는다.
Relation to the Verifiable Credentials Data Model
이 규격은 검증 가능한 크리덴셜 데이터 모델의 인코딩 규칙을 JWT 및 JWS에 정의한다.
또한 JWT에 기초한 시스템이 이 규격을 준수할 수 있도록 특정 JWT 형식에
등록된 클레임의 이름과 특정 JWS 등록 헤더 파라미터 이름을
언제 어떻게 사용하는지를 정의한다.
이러한 특정 클레임의 이름과 헤더 파라미터가 존재하는 경우,
그에 대응되는 표준 검증가능한 크리덴셜과 검증가능한 프리젠테이션은 중복 방지를 위해 생략될 수 있다.
JSON Web Token Extensions
This specification introduces two new registered claim names, which
contain those parts of the standard verifiable credentials and
verifiable presentations where no explicit encoding rules for JWT exist.
These objects are enclosed in the JWT payload as follows:
이 규격은 JWT에 대한 명시적 인코딩 규칙이 존재하지 않는
표준 검증가능한 크리덴셜 및 검증가능한 프리젠테이션의 일부를 포함하는
새로 등록된 두 개의 클레임의 이름에 대해 소개한다.
이러한 객체들은 다음과 같이 JWT 전송 데이터에 포함되어있다
명시적 규칙이 지정되지 않은 경우 속성들은 표준 검증가능한 크리덴셜과 동일한 방식으로 인코딩되며
JWT의 vc클레임에 추가된다. 모든 JWT와 마찬가지로, JWT 구문에 표시된 검증가능한 크리덴셜의
JWS 기반 서명은 디코딩 또는 변환 규칙 적용 전의 JWT 문자열 값에 대해 계산된다.
다음 단락은 이러한 인코딩 규칙을 설명한다.
JWS가 없는 경우 반드시 proof속성을 제공해야 한다.
proof속성은 작성자가 발급자와 다른 경우에 필요할 수 있고,
작업 증명과 같은 디지털 서명에 근거하지 않은 증명을 나타내기 위해 사용될 수 있다.
발급자는 검증가능한 크리덴셜에 JWS와 proof속성을 모두 포함할 수 있다.
하지만 역호환성을 고려한다면 발급자는 JWS를 사용하여 디지털 서명에 기반한 증명을 나타내야 한다.
다음 규칙은 이 규격의 context에서 JOSE 헤더에 적용된다.
alg는 디지털 서명을 위해 반드시 설정되어야 한다.
선택한 서명 방법에 proof속성만 필요한 경우(즉, 해당 메소드 내에 선택한 알고리즘이 없는경우)
alg 헤더를 none으로 설정해야 한다.
JWT 발급자와 관련된 키가 여러 개 있는 경우 kid를 사용할 수 있다.
주요 과정은 이 규격의 범위를 벗어난다.
예를 들어, kid는 DID 문서의 키를 참조하거나 JWKS 내부의 키 식별자가 될 수 있다.
typ가 있는 경우 JWT로 설정해야 함
JWT 프로세서와의 역호환성을 위해,
다음의 JWT 형식에 등록된 클레임 명칭은 반드시 각각에 대응되는 표준 검증가능한 크리덴셜 대신,
또는 추가로 사용되어야 한다.
exp는 expirationDate속성을 나타내야 하고
UNIX 타임스탬프(NumericDate)로 인코딩되어야 한다.
명시적으로 사용이 금지되어있지 않다면
본 문서에 명시되지 않은 다른 JOSE 헤더 매개변수 및 JWT 클레임 이름을 사용할 수 있다.
추가적인 검증가능한 크리덴셜클레임은 JWT의 credentialSubject 속성에 추가되어야 한다.
여기에 지정되지 않은 JOSE 헤더 매개 변수 및/또는 JWT 클레임 이름 사용에 대한
자세한 내용은 검증 가능한 크리덴셜 구현 지침 [VC-IMP-GUIDE] 문서를 참조하시오.
이 규격 버전은 섹션 고급 개념
(예: refreshService, termsOfUse 및 evidence)에 요약된 개념에 대한
JWT별 인코딩 규칙을 정의하지 않는다.
이러한 개념은 별도의 변환 없이 그대로 인코딩할 수 있으며,
JWT의 vc클레임에 추가될 수 있다.
이 규격은 Linked Data를 이용하여 URL, JSON-LD와 같은 표준을 사용하여
웹에 정보를 게시하여 주체와 관련 속성을 식별한다.
이러한 방식으로 정보를 제시하면 다른 관련 정보를 쉽게 발견할 수 있고
새로운 정보를 기존의 지식 그래프로 쉽게 통합할 수 있다.
Linked Data는 분산된 방식으로 확장 가능하여 대규모 통합에 대한 장벽을 크게 줄인다.
이 규격의 데이터 모델은 이 규격에 설명된 대로 데이터 모델을 보호하도록 설계된
Linked Data Proofs,
Linked Data Signatures 및
관련 Linked Data Cryptographic Suites와 잘 작동한다.
JSON Web Token의 사용과 달리 별도의 사전 또는 후처리는 필요하지 않다.
Linked Data Proofs 형식은 검증가능한 크리덴셜과 검증가능한 프레젠테이션을
간단하고 쉽게 보호하도록 설계되었다. 검증가능한 크리덴셜 또는
검증가능한 프레젠테이션을 보호하는 것은 이 규격의 유효한 예를
Linked Data Signatures 구현에 전달하고 디지털 서명을 생성하는 것만큼 간단하다.
Note
다양한 syntax 형식(예: JSON+JWT, JSON-LD+JWT 또는 JSON-LD+LD-Proofs)의 다양한 품질에 대한 자세한 내용은
검증 가능한 크리덴셜 구현 지침 [VC-IMP-GUIDE] 문서를 참조하십시오.
4.4 Privacy Considerations
이 부분은 비규범적입니다.
이 섹션에서는 검증가능한 크리덴셜 데이터 모델을
프로덕션 환경에 배포할 때의
일반적인 프라이버시 고려사항 및 특정 프라이버시 관련 영향에 대해 자세히 설명한다.
4.4.1 Spectrum of Privacy
이 부분은 비규범적입니다.
익명부터 강하게 식별되는 범위에 이르는 프라이버시의 범주가 있음을 인지하는 것은 중요하다.
사례에 의하면, 사람들은 제공하고자하는 정보와 제공되는 정보에서 파생된 정보에 대해 서로 다른 안도감의 단계를 가지고 있다
그림 12
익명부터 완전히 식별되는 범위에 이르는 프라이버시의 범주
예를 들어, 대부분의 사람들은 주류를 구입할 때 익명을 유지하기를 원하는데 그 이유는 필요한 규제 확인은 전적으로 그 사람이 특정 연령 이상인지 여부에 달려있기 때문이다. 그 대신, 의사가 환자를 위해 작성한 의료 처방전의 경우, 처방을 이행하는 약국은 의료 전문자와 환자를 강하게 식별해야 한다. 따라서 모든 사례에 적합한 하나의 프라이버시 접근법은 없다. 프라이버시 해결책은 사례에 따라 다르다.
Note
주류를 구입할 때 익명을 유지하려는 경우에도, 상인에게 적절한 보증을 제공하기 위해 사진 신분증이 필요할 수 있다. 상인은 (당신이 특정 연령 이상이라는 것 이외에) 당신의 이름이나 다른 세부 정보를 알 필요가 없지만, 많은 경우 나이 증명은 규정을 충족하기에 아직 불충분하다.
검증가능한 크리덴셜 데이터 모델은 전체 프라이버시 범주를 지원하기 위해 노력하고 있으며, 어떤 특정 트랜잭션에 대해서도 올바른 수준의 익명성에 대한 철학적 입장을 취하지 않는다. 다음 섹션은 프라이버시에 적대적인 특정 시나리오들을 피하려는 구현자들을 위한 지침을 제공한다.
4.4.2 개인식별정보
이 부분은 비규범적입니다.
credential.credentialSubject 필드에 저장된 검증가능한 크리덴셜 관련 데이터는
검증자와 공유할 경우 프라이버시 침해를 허용할 수 있다. 정부에서 발행한 식별자,
배송지 주소, 성명 등과 같은 개인식별정보는 개체를 특정하거나 추적하고 상관관계를
확인하는데 쉽게 사용될 수 있다. 비록 생일과 우편번호의 조합 같이 개인을 식별별하는데
쓸 수 없을 것 같은 정보라도 매우 강력한 상관관계 및 재식별화(De-anonymizing)의
가능성을 가지고 있다.
구현자는 이러한 종류의 특성을 가진 데이터를 공유할 경우 보유자에게 경고할 것을 강력하게
권고한다. 발행자는 가능하면 프라이버시를 보호하는 검증가능한 크리덴셜을 제공할 것을
강력하게 권고한다. 예를들면, 검증자가 개체의 성인 여부를 확인하고자 하면, 생년월일을
담은 검증가능한 크리덴셜을 발행하는 대신 ageOver검증가능한 크리덴셜을 발행하는 것이다.
검증가능한 크리덴셜은 종종 개인식별정보(PII)를 포함하고 있기 때문에, 구현자는
검증가능한 크리덴셜을 저장하고 전송하는 과정에서 접근하지 말아야 할 사람들로부터
데이터를 보호하기 위한 메커니즘을 사용하도록 해야 한다. 고려할 수 있는 매커니즘은
전송계층보안(TLS, Transport Layer Security) 또는 그 외에 데이터 전송시에는 데이터를
암호화하고 전송 중이 아니더라도 검증가능한 크리덴셜의 데이터를 암호화하거나 접근
제어하는 수단이 있을 수 있다.
4.4.3 식별자 기반 상관관계
이 부분은 비규범적입니다.
검증가능한 크리덴셜의 주체는 credential.credentialSubject.id 필드를 사용하여
식별된다. 주체를 식별하기 위해 사용되는 식별자는 식별자의 수명이 길고 하나 이상의
웹 도메인을 넘나들며 사용될 경우 더 큰 상관관계의 위험을 야기한다.
유사하게, 크리덴셜 식별자(credential.id)를 공개하는 것은러 검증자가 결탁하거나
혹은 발급자와 검증자가 결탁하여 보유자와의 상관관계를 파악할 수 있는 상황으로 이끌
수 있다. 만약 보유자가 상관관계를 줄이고 싶다면, 검증가능한 프레젠테이션을 하는 동안
식별자를 숨기는 검증가능한 크리덴셜 스킴을 사용해야 한다. 그러한 스킴은 보유자가
식별자를 생성하고 사용자로부터 식별자를 숨기는 것을 허용하는 한편 식별자를 검증가능한 크리덴셜
안에 포함하고 서명할 수 있도록 유지한다.
만약 강력한 상관관계 방지 속성이 요구되는 검증가능한 크리덴셜 체계인 경우, 식별자는
다음 중 하나를 만족하도록 강력히 권고된다:
단일 기원(Single origin)으로 향함
P
단일 사용(Single use)
한번도 사용되지 않았지만 짧은 수명의 단일 사용 전달자 토큰으로 교체됨
4.4.4 서명 기반의 상관관계
이 부분은 비규범적입니다.
검증가능한 크리덴셜의 내용은 credential.proof 필드를 사용하여 보호한다. 이 필드의
속성들은 같은 값이 하나 이상의 세션 혹은 도메인에서 사용되고 그 값이 변하지 않을 경우
더 큰 상관관계의 위험을 만들 수 있다. verificationMethod, create, proofPurpose,
jws 필드가 이에 속한다.
만약 강력한 상관관계 방지(Anti-Correlation) 속성이 필요할 경우, 제3자 쌍 서명,
영지식증명 또는 집단 서명 등의 기술을 사용하여 매번 서명값과 메타데이터를 재생성하는
것을 권장한다.
Note
비록 상관관계 방지용 서명을 사용하더라도, 검증가능한 크리덴셜에는 사용된 암호 기술의
상관관계 방지 속성을 무력화시킬 수 있는 정보가 여전히 포함될 수 있다
4.4.5 수명이 긴 식별자 기반의 상관관계
이 부분은 비규범적입니다.
Verifiable credentials might contain long-lived identifiers that could
be used to correlate individuals. These types of identifiers include
subject identifiers, email addresses, government-issued identifiers,
organization-issued identifiers, addresses, healthcare vitals,
verifiable credential-specific JSON-LD contexts, and many other sorts of
long-lived identifiers.
검증가능한 크리덴셜은 개인의 상관관계를 파악하는데 사용될 수 있는 수명이 긴 식별자를
포함할 수 있다. 이러한 종류의 식별자에는 주체 식별자, 이메일 주소, 정부 발행 식별자,
조직 발행 식별자, 주소, 헬스케어 바이탈, 검증가능한 크리덴셜 특화 JSON-LD 컨텍스트,
그리고 수 많은 종류의 수명이 긴 식별자가 포함된다.
보유자에게 소프트웨어를 제공하는 조직은 개인의 상관관계를 파악하는데 사용되는 정보가
포함된 검증가능한 크리덴셜의 필드를 식별하여, 이 정보가 공유될 때 보유자에게 경고해야 한다
4.4.6 디바이스 핑거프린팅
이 부분은 비규범적입니다.
인터넷과 웹상에서 개인을 추적하고 상관관계를 파악하는데 사용되는 검증가능한 크리덴셜
외부의 메커니즘들이 있다. 이러한 메커니즘은 인터넷 프로토콜(IP) 주소 추적,
웹 브라우저 핑거프린팅, 에버쿠키(evercookie), 광고 네트워크 추적기,
모바일 네트워크 위치 정보, 인앱 GPS API 등을 포함한다. 검증가능한 크리덴셜을
사용하는 것이 이러한 기술을 사용하는 것을 막지는 못한다. 또한, 이러한 기술들이
검증가능한 크리덴셜과 결합되어 사용되면 새로운 상관관계를 파악할 수 있는
정보들을 발견할 수도 있다. 예를 들어, 생일과 GPS 위치를 결합하면 다수의
웹사이트에서 개인에 대한 강력한 상관관계를 파악하는데 사용될 수 있다.
개인정보보호를 중요하게 여기는 시스템에서 검증가능한 크리덴셜을 사용하는 경우,
이러한 추적 기술들의 사용을 방지하도록 하는 것이 권장한다. 경우에 따라서는 보유자를
대신하여 검증가능한 크리덴셜을 전송하는 기기에서 추적 기술들이 비활성화 하는 것도 요구될 수 있다.
4.4.7 추상 클레임 선호(Flavor Abstract Claim
이 부분은 비규범적입니다.
검증가능한 크리덴셜을 받는 사람이 필요 이상으로 개인식별정보를 노출하지 않으면서도
다양한 상황에서 활용할 수 있도록 하기 위해 발행자는 크리덴셜의 정보를 예상되는 목적에
필요한 최소한의 정보로 제한하는 것을 고려해야 한다. 개인식별정보를 크리덴셜에 포함하지
않도록 하는 방법 중 하나는 주체에 대한 특정한 정보를 제공하지 않으면서도 검증자의
요구를 만족시키는 추상 속성을 사용하는 것이다.
예를 들면, 본 문서는 강력한 개인식별정보인 생일을 사용하는 대신 ageOver속성을 사용한다.
만약 특정 시장의 소매업자가 일반적으로 구매자에게 특정 나이 이상을 요구하는 경우,
그 시장에서 신뢰받는 발행자는 주체의 생일에 대한 클레임을 포함하는 검증가능한 크리덴셜을
제공하기 보다는 주체가 그 조건을 만족한다고 주장하는 검증가능한 크리덴셜을 제공하는 것을
선택할 것이다. 이로인해 개인 소비자가 특정 개인식별정보를 드러내지 않으면서도 구매를 할 수 있게 된다.
4.4.8 데이터 최소화 원칙
이 부분은 비규범적입니다.
한 컨텍스트에서 유출된 정보가 다른 컨텍스트로 유출되면 개인정보보호 위반이 발생한다.
이러한 위반을 방지하기 위해 허용되는 모범 사례는 요청 및 수신한 정보를 최소한으로
제한하는 것 이다. 데이터 최소화 접근법은 미국의
HIPAA (Health Insurance Portability and Accountability Act) 및 EU의
GDPR (General Data Protection Regulation)을 포함한 여러 관할권의 규정에 의해
요구된다.
발급자를 위한 데이터 최소화가 뜻하는 것은 검증가능한 크리덴셜의 사용을
예상하여 잠재적 검증자가 요구하는 최소값으로 제한하는 것을 의미한다.
검증자의 경우 데이터 최소화는 서비스 접근에 요구 또는 정보의 범위를 제한하는
것을 의미한다.
예를 들어, 면허 번호, 키, 몸무게, 생일, 주소가 포함된 운전 면허증은 개인이 특정 연령
이상임을 확인하는데 필요한 것보다 많은 정보가 포함된 크리덴셜이다.
발급자가 정보를 원자화하거나 선택적 공개를 허용하는 서명 체계를 사용하는
것이 가장 좋은 사례이다. 예를 들어, 운전면허 발급자는 운전 면허에 나타나는
모든 속성이 포함된 검증가능한 크리덴셜과 개인의 생일과 같은 단일 속성만
포함되는 검증가능한 크리덴셜 집합을 발급할 수 있다. 또한, 더 추상적인
검증가능한 크리덴셜을 발행할 수 있다 (예 : ageOver 특성만
포함하는 검증가능한 크리덴셜). 한 가지 가능한 적용 방법은 발급자가
검증가능한 크리덴셜의 익명 사용을 촉진하는 일회용 무기명 크리덴셜을
검색하기 위한 보안 HTTP 엔드포인트를 제공하는 것이다. 부적절하거나 위험을 발견한
구현자는 선택적 공개를 사용하여 발급자에 대한 의존성을 제거하고
발급자의 일시적인 상관 위험을 줄여야 한다.
검증자는 특정 트랜젝션이 발생하는데 꼭 필요한 정보만 요청해야 한다.
이는 두 종류의 이유로 중요하다:
최소 공개 원칙을 실행하는 것은 가능하지만, 단일 또는 다중 세션 동안 특정 사례에서
개인의 강력한 식별을 피하는 것은 불가능할 수 있다. 본 표준의 저자는 실제 시나리오에서
원칙을 달성하는 것은 어려울 수 있다고 강요하지 않는다.
4.4.9 무기명 크리덴셜
이 부분은 비규범적입니다.
무기명 크리덴셜은 콘서트 티켓과 같은
개인정보보호 강화 정보로, 보유자에게는 자신에 대한 민감한 정보를 공개하지
않고도 특정 자원에 대한 크리덴셜을 부여 할 수 있다. 무기명 크리덴셜은 종종
무기명 크리덴셜 공유가 문제가 되지 않거나 경제적 또는 평판의 손실이 크지 않은
저 위험 사례에서 사용된다.
무기명 크리덴셜은 개인정보보호를 강화할 수 있지만, 무기명 크리덴셜보유자가 예상한 것보다 더 많은 정보를 실수로 공개하지 않도록 신중하게 만들어야
한다. 예를 들어, 다수의 사이트에서 동일한 무기명 크리덴셜을 반복적으로 사용하면
사이트들이 담합하여 잠재적으로 보유자를 추적하거나 연동시킬 수 있다.
또한 생년월일 및 우편 번호와 같이 식별할 수 없는 것처럼 보이는 정보를 사용하여 동일한
무기명 크리덴셜 또는 세션에서 함께 사용될 경우, 개인을 통계적으로 식별할 수 있다.
민감한 정보가 포함된 무기명 크리덴셜이 발행, 요청되거나 하나 이상의 세션에서
두 가지 이상의 무기명 크리덴셜을 결합되거나 상관 관계 위험이 있는 경우,
소프트웨어는 보유자에게 경고해야 한다. 모든 상관 관계 위험을 감지하는 것은
불가능하지만 일부는 확실하게 감지할 수 있다.
이러한 검사를 수행하면 정보 유출로 인해 보유자의 개인정보보호 위반이
발생할 수 있다. 예를 들어 폐기 목록 확인과 같은 간단한 조작으로 특정 비즈니스가
보유자와 상호작용 한다는 것을 발급자에게 알릴 수 있다.
이는 발급자들은 담합과 연동을 개인들에 대한 정보 없이 할 수 있다.
발급자는 크리덴셜마다 검증과정에서 개인정보보호 위반이 발생할
수 있는 구간에 크리덴셜마다 고유한 폐기 목록과 같은 메커니즘을 사용하지
않아야 한다. 보유자에게 소프트웨어를 제공하는 조직은 크리덴셜 검증 과정
중에 개인정보보호 위반으로 이어질 수 있는 정보가 포함된 경우 경고해야 한다.
검증자는 개인정보 침해를 유발하거나 개인정보보호 정책을 위반하는
크리덴셜을 거부해야 한다.
4.4.11 Storage Providers and Data Mining
이 부분은 비규범적입니다.
When a holder receives a verifiable credential from an
issuer, the verifiable credential needs to be stored somewhere
(for example, in a credential repository). Holders are warned that
the information in a verifiable credential is sensitive in nature and
highly individualized, making it a high value target for data mining. Services
that advertise free storage of verifiable credentials might in fact be
mining personal data and selling it to organizations wanting to build
individualized profiles on people and organizations.
Holders need to be aware of the terms of service for their
credential repository, specifically the correlation and data mining
protections in place for those who store their verifiable credentials
with the service provider.
Some effective mitigations for data mining and profiling include using:
Service providers that do not sell your information to third parties.
Software that stores verifiable credentials locally on a device that you
control and that does not upload or analyze your information beyond your
expectations.
4.4.12 Aggregation of Credentials
이 부분은 비규범적입니다.
Holding two pieces of information about the same subject almost always
reveals more about the subject than just the sum of the two pieces, even
when the information is delivered through different channels. The aggregation of
verifiable credentials is a privacy risk and all participants in
the ecosystem need to be aware of the risks of data aggregation.
For example, if two bearer credentials, one for an email address and then
one stating the holder is over the age of 21, are provided across
multiple sessions, the verifier of the information now has a unique
identifier as well as age-related information for that individual. It is now
easy to create and build a profile for the holder such that more and more
information is leaked over time. Aggregation of credentials can also be
performed across multiple sites in collusion with each other, leading to privacy
violations.
From a technological perspective, preventing aggregation of information is a
very difficult privacy problem to address. While new cryptographic techniques,
such as zero-knowledge proofs, are being proposed as solutions to the problem
of aggregation and correlation, the existence of long-lived identifiers and
browser tracking techniques defeats even the most modern cryptographic
techniques.
The solution to the privacy implications of correlation or aggregation tends not
to be technological in nature, but policy driven instead. Therefore, if a
holder does not want information about them to be aggregated, they must
express this in the verifiable presentations they transmit.
4.4.13 Usage Patterns
이 부분은 비규범적입니다.
Despite the best efforts to assure privacy, actually using
verifiable credentials can potentially lead to de-anonymization and a
loss of privacy. This correlation can occur when:
The same verifiable credential is presented to different
verifiers, and either those verifiers collude or a third party
has access to transaction records from both verifiers. An observant
party could infer that the individual presenting the
verifiable credential is the same person at both services. That is, the
accounts are controlled by the same person.
The underlying information in a credential can be used to identify an
individual across services. In this case, using information from other sources
(including information provided directly by the holder), verifiers
can use information inside the credential to correlate the individual
with an existing profile. For example, if a holder presents
credentials that include postal code, age, and gender, a verifier
can potentially correlate the subject of that credential with an
established profile. For more information, see [DEMOGRAPHICS].
Passing the identifier of a credential to a centralized revocation
server. The centralized server can correlate the credential usage across
interactions. For example, if a credential is used for proof of age in
this manner, the centralized service could know everywhere that
credential was presented (all liquor stores, bars, adult stores, lottery
purchases, and so on).
In part, it is possible to mitigate this de-anonymization and loss of privacy
by:
Using a globally-unique identifier as the subject for any given
credential and never re-use that credential.
If the credential supports revocation, using a globally-distributed
service for revocation.
Designing revocation APIs that do not depend on submitting the ID of the
credential. For example, use a revocation list instead of a query.
Avoiding the association of personally identifiable information with any
specific long-lived subject identifier.
It is understood that these mitigation techniques are not always practical
or even compatible with necessary usage. Sometimes correlation is a
requirement.
For example, in some prescription drug monitoring programs, usage monitoring is
a requirement. Enforcement entities need to be able to confirm that individuals
are not cheating the system to get multiple prescriptions for controlled
substances. This statutory or regulatory need to correlate usage overrides
individual privacy concerns.
Verifiable credentials will also be used to intentionally correlate
individuals across services, for example, when using a common persona to log in
to multiple services, so all activity on each of those services is
intentionally linked to the same individual. This is not a privacy issue as
long as each of those services uses the correlation in the expected manner.
Privacy risks of credential usage occur when unintended or unexpected
correlation arises from the presentation of credentials.
4.4.14 잘못된 당사자에게 정보 공유
이 부분은 비규범적입니다.
어떤 보유자가 어떤 검증자와 정보를 공유하기로 결정했을 때,
그 검증자는 정직하지 못하게 행동하면서 보유자에게 해를 끼치는데 사용할 수 있는 정보를 요청하는 경우가 발생할 수 있다.
예를 들어, 검증자는 은행 계좌 번호를 요청하고 다른 정보와 함께 사용함으로써 보유자나 은행을 속일 수 있다.
발급자는 가능한 많은 정보를 토큰화함으로써,
보유자가 뜻하지 않게 크리덴셜들을 잘못된 검증자에게 전달한 경우에도,
그 상황이 재앙이 되지 않도록 노력해야 한다.
예를 들어 개인의 은행 잔고를 확인하기 위해 은행 계좌 번호를 (검증가능한 크리덴셜에) 포함하는 대신에,
잔액이 얼마 이상인지만 검증자가 확인하는데 사용할 수 있는 토큰을 제공할 수 있다.
이 경우에 은행은 잔액 확인용 토큰이 포함된 검증가능 크리덴셜을 보유자에게 발급할 수 있다.
보유자는 그 검증가능한 크리덴셜을 검증가능한 프레젠테이션에 포함하고,
전자 서명을 이용하여 그 토큰을 신용 조회 기관에 결합시킨다.
검증자는 그들의 전자서명으로 검증가능한 프레젠테이션을 한번 감싸고,
그것을 발급자에게 돌려주므로써 동적으로 계좌 잔액을 확인할 수 있다.
이러한 접근 방식을 이용하여, 보유자가 계좌 잔액 토큰을 잘못된 당사자에게 공유했다 하더라도
공격자는 은행 계좌 번호나 정확한 계좌 잔고를 알 수 없게 된다.
그리고 (보유자의) 카운터 서명에 주어진 유효 기간으로 인해, 몇 분이 지나면 토큰에 대한 접근 권한을 얻지 못하게 된다.
예를 들어, ageOver검증가능 크리덴셜은 술집 출입 가능 여부를 판단하는데 유용하다.
만약 발급자가 그러한 검증가능 크리덴셜을 아주 짧은 만료 시기와 자동 갱신 메커니즘으로 발급한다면,
발급자는 보유자의 행위를 보유자에게 부정적인 영향을 미치는 방식으로 연관시킬 수 있다.
보유자에게 소프트웨어를 제공하는 조직들은 보유자가 짧은 수명을 가진 크리덴셜을 반복적으로 사용하는 경우에
보유자에게 행위 연관성이 발생할 수 있음을 경고해야 한다.
발급자는 사용 패턴을 연관시키는 방식의 크리덴셜 발급을 피해야한다.
4.4.16 일회용 크리덴셜 선호
이 부분은 비규범적입니다.
이상적인 사생활 존중 시스템은 검증자와 상호작용하기 위해 필요한 정보만을 보유자가 공개하도록 요구한다.
검증자는 공개 요구사항을 만족하는 정보만을 기록하고, 공개된 정보 중 나머지 민감한 정보는 저장하지 않는다.
많은 경우에 규제적인 부담과 같은 우선순위의 경쟁으로 인해 이런 이상적인 시스템을 채택하는 것이 쉽지 않다.
다른 경우는, 수명이 긴 식별자가 일회성을 저해한다.
그러나 모든 검증가능한 크리덴셜 생태계의 설계는 가능할 때마다 일회용 검증가능한 크리덴셜을 선호함으로써 사생활을 존중하기 위해 노력해야 한다.
일회용 검증가능한 크리덴셜을 사용하는 것은 여러가지 이점이 있다.
첫번째 이점은 검증자 입장에서 검증가능한 크리덴셜에 있는 데이터가 최신이라는 것을 확신할 수 있다는 점이다.
두번째 이점은 보유자 입장에서 만약 수명이 긴 식별자가 검증가능한 크리덴셜에 존재하지 않는다면
검증가능한 크리덴셜 자체는 온라인 상에서 자신을 추적하거나 연관시킬 수 없다는 점을 알게된다는 점이다.
마지막으로 공격자가 훔칠만한 것이 존재하지 않기 때문에 운영되는 전체 생태계가 더 안전해진다는 것이다.
4.4.17 시크릿 브라우징 모드
이 부분은 비규범적입니다.
이상적인 시크릿 브라우징 모드 시나리오에서는,
어떤 개인 개인식별정보(PII, Personally Identifiable Information)도 노출되지 않을 것이다.
많은 크리덴셜들이 개인식별정보를 포함하고 있기 때문에,
소프트웨어를 제공하는 조직들은 시크릿 브라우징 모드에서 크리덴셜과 프레젠테이션을 사용하면
개인식별정보가 노출될 수 있음을 보유자에게 경고해야 한다.
각 브라우저 공급자들마다 시크릿 모드를 처리하는 방식이 다르고,
어떤 브라우저는 이러한 경고 기능을 제공하지 않을 수도 있기 때문에,
구현자들이 이러한 차이점을 인지하고 그에 맞게 솔루션을 구현하는 것이 중요하다.
4.5 보안 고려사항
이 부분은 비규범적입니다.
발급자, 보유자, 검증자가 이 명세서에서 설명하고 있는 데이터를 처리할 때 인지하고 있어야 하는 보안 고려사항이 아주 많이 있다.
이 섹션에서 설명하는 내용이 함축하는 바를 무시하거나 이해하지 못한다면 보안 취약점이 발생할 수 있다.
이번 섹션에서 다양한 보안 고려사항을 강조하고 있지만, 이것이 완전한 리스트는 아니다.
구현자는 이 명세서에서 서술한 기술을 이용하여 미션 크리티컬한 시스템을 구축하는 경우,
보안과 암호학 전문가들에게 추가적인 조언을 구해야 한다.
4.5.1 암호화 스위트와 라이브러리
이 부분은 비규범적입니다.
이 명세서에서 설명한 데이터 모델의 일부 측면은 암호학을 이용하여 보호할 수 있다.
구현자가 크리덴셜과 프레젠테이션을 생성하고 처리함에 있어서 사용되는 암호화 스위트와 라이브러리를 이해하는 것은 중요하다.
암호화 시스템을 구축하고 감사하는 것은 일반적으로 상당한 경험을 필요로 한다.
효과적인 레드팀 구성을 통해 보안성 리뷰에서 나타날 수 있는 편향을 방지할 수 있다.
암호화 스위트와 라이브러리는 일종의 유통기한이 있어서 결국 새로운 공격과 기술 발달에 노출된다.
제품 품질 관리 시스템은 이러한 특성을 고려하여 만료되거나 깨진 암호화 수트와 라이브러리를
간단히 선제적으로 업그레이드가 가능하도록 구성하고,
이미 발급된 크리덴셜을 무효화하고 교체할 수 있는 메커니즘을 보장해야 한다.
주기적인 모니터링은 크리덴셜을 처리하는 시스템의 장기 생존을 보장하는데 중요하다.
4.5.2 Content Integrity Protection
이 부분은 비규범적입니다.
검증가능한 크리덴셜에는 외부에서 자신을 검증하기 위한 검증가능한 크리덴셜을 가르키는 URL들이 종종 포함되어 있다. 외부에 존재하는 이미지, JSON-LD 컨택스트 및 기계판독가능데이터들과 같은 링크된 컨텐츠는 검증가능한 크리덴셜의 증명을 통한 보호에서 벗어나 있기 때문에, 변조로 부터 종종 보호되지 않는다. 예를 들어 다음과 같이 강조표시된 링크들은 컨탠츠 무결성이 보호되지 않지만, 아마도 다음과 같을 것이다.
이 규격에서 컨텐츠 무결성 보호를 위해 특정한 방법을 권장하지 않지만, 링크된 컨탠츠의 무결성 보호를 원하는 작성자는 컨탠츠 무결성을 강화하는 URL체계를 사용할 것을 권장한다. 이러한 2가치 체계는 [HASHLINK]규격과 [IPFS]이다. 다음의 예제는 이전의 예를 변형해서 [HASHLINK]규격을 이용해 JSON-LD 컨텍스트에 콘텐츠 무결성 보호를 추가하고, [IPFS] 링크를 사용하여 이미지에 콘텐츠 무결성 보호를 추가하였다.
예시 35: Content-integrity protection for links to external data
프로덕션 구현에는 중요한 JSON-LD 컨텍스트의 정적 사본이 제공 될 것으로 예상되므로, 위의 JSON-LD 컨텍스트에 보호가 필요한지 여부는 논란의 여지가 있다.
위의 예는 컨텐츠 무결성 보호를 달성하는 한 가지 방법이지만 특정 애플리케이션들에 더 적합한 다른 솔루션들이 있습니다. 구현자들은 컨텐츠 무결성으로 보호되지 않는 외부의 기계판독가능한 컨텐츠들에 대한 링크가 어떻게 그들의 어플리케이션에 대한 성공적인 공격을 만들어 낼 수 있는지 이해해야 합니다.
4.5.3 Unsigned Claims
이 부분은 비규범적입니다.
이 규격은 어떠한 서명이나 증명도 포함하지 않은 크리덴셜을 만들 수 있도록 한다. 이러한 유형의 크리덴셜은 웹 페이지에서 양식을 작성하는 것과 유사한 자가증명, 중간 저장소에 종종 유용하다. 구현자는 이러한 종류의 크리덴셜들은 작성자가 알려지 있지 않거나, 신뢰할 수 없기 떄문에 검증할 수 없다는걸 알아야 한다.
4.5.4 Token Binding
이 부분은 비규범적입니다.
검증자는 이것이 중간자 공격의 목표가 아닌 검증가능한 프레젠테이션의 수신자인지 확인해야 할 수도 있다. 요청에 의해서 검증가능한 프레젠테이션 응답을 묶은 토큰바인딩 [RFC8471]과 같은 접근 방법으로 프로토콩을 보호할 수 있다. 보안되지 않은 모든 프로토콜은 중간자 공격에 취약하다.
4.5.5 Bundling Dependent Claims
이 부분은 비규범적입니다.
발급자가 크리덴셜의 정보를 원자화하거나, 선택정공개를 허용하는 서명체계를 이용하는 것이 가장 좋다. 원자화의 경우에, 만약 발급자에 의해 안전하게 완료되지 않았다면, 발급자가 의도하지 않은 방식으로 보유자의 다른 크리덴셜과 묶일 수 있다.
예를 들어, 대학은 한사람에게 2종류의 검증가능한 크리덴셜을 발급할 수 있는데, 각 자격증에는 "컴퓨터 부서"의 "담당자" 또는 "경제학과"의 "대학원생"과 같이 주어진 "부서"와 "역할"의 2가지 속성이 각각 포함되어 있습니다. 만약 이러한 속성들 중 단지 하나만이 크리덴셜에 포함되어 원자화된다면, 대학은 한사람에게 4개의 크리덴셜을 발급해야 합니다. 각각의 크리덴셜들은 "직원", "대학원생", "컴퓨터 부서", "경제학과"가 될 것이다. 보유자는 검증자에게 "직원"과 "경제학과"의 검증가능한 크리덴셜을 전송할 수 있으며, 이는 잘못된 클레임이 된다.
4.5.6 Highly Dynamic Information
이 부분은 비규범적입니다.
높은 동적인 정보에 대한 검증가능한 크리덴셜을 발급하는 경우, 구현자는 만료기간을 적절하게 설정해야합니다. 검증가능한 크리덴셜의 유효기간보다 만료기간이 더 길다면 악용가능한 보안취약성이 발생할 수 있다. 검증가능한 크리덴셜을 통해 표현되는 정보의 만료기간이 유효기간보다 짧으면 보유자와 검증자에게 부담을 줍니다. 따라서 사용사례와 검증가능한 크리덴셜에 포함된 정보의 예상 수명에 유효기간의 적절한 설정은 중요하다.
4.5.7 Device Theft and Impersonation
이 부분은 비규범적입니다.
검증가능한 크리덴셜이 저장된 장치가 분실되거나 도난당했을 때, 공갹자가 피해자의 검증가능한 크리덴셜을 사용하여 시스템에 접속할 수 있다. 이러한 유형의 공격을 완화하는 방법:
구현자가 이 규격에 기술된 데이터를 처리할 때 알아야할 많은 접근성에 대한 고려사항이 있다. 모든 웹표준 또는 프로토콜의 구현과 마찬가지로 접근성 문제에 대한 무시하게 되면 모집단의 상당부분에서 이 정보를 이용할수 없게 된다. [WCAG21]과 같은 접근성 가이드라인과 표준을 지켜 모든 사람들이 능력에 개의치 않고 이 정보를 사용할 수 있게 만드는 것은 매우 중요하다. 역사적으로 보조기술에 문제를 야기한 암호학을 이용한 시스템을 구축할 때 이것은 특별히 중요하다.
이 절에서는 이 데이터 모델을 활용할 때 고려해야 할 일반적인 접근성에 대한 고려사항을 자세히 설명한다.
4.6.1 Data First Approaches
이 부분은 비규범적입니다.
정부에서 발행한 신분증과 같이 오늘날 사용하고 있는 많은 물리적인 인증들은 인쇄가 너무 작거나, 작지만 고해상도의 이미지에 의존하거나, 시각적 장애를 가진 사람들에게 제공할 수 없는 등의 제약이 포함되어 있는 특징들에 의해 접근성이 매우 열악하다.
데이터모델을 이용해 검증가능한 크리덴셜을 만들때, 데이터 모델 디자이너는 데이터 우선 접근 방식을 사용하는 것이 좋습니다. 예를 들어, 크리덴셜을 묘사하기 위해 데이터 또는 그래픽 이미지를 사용하기로 선택한 경우, 디자이너는 기관의 이름 또는 전문 자격과 같은 이미지의 모든 요소를 시청자의 해석에 의존하지 말고 기계판독이 가능한 방식으로 표현해야합니다. 데이터 우선 접근 방식은 다양한 능력을 가진 사람들을 위해 서로 다른 인터페이스를 구축을 위한 기본 요소를 제공하기 때문에 선호됩니다.
4.7 국제화 고려 사항
이 부분은 비규범적입니다.
구현자는 이 사양에 설명 된 데이터를 게시 할 때 여러 국제화 고려 사항을 알고 있어야 한다.
웹 표준 또는 프로토콜 구현과 마찬가지로 국제화를 무시하면
데이터의 다른 언어와 사회에서 데이터를 생성하고 소비하기가 어려워지므로
사양의 적용 가능성이 제한되고 표준으로서의 가치가 크게 떨어진다.
구현자는 국제화를 지원하기 위해 텍스트에 대한 신뢰할 수 있는 메타 데이터를 제공하는
W3C 국제화 활동에서 발행 한
웹에서 문자열 : 언어 및 방향 메타 데이터 문서 [STRING-META] 읽기를 권장한다.
국제화 고려 사항에 대한 최신 정보를 얻으려면
구현자는 확인 가능한 자격 증명 구현 지침 [VC-IMP-GUIDE] 문서를 읽어야한다.
이 섹션에서는이 데이터 모델을 사용할 때 고려해야 할 일반적인 국제화 고려 사항에 대해 간략하게 설명하고 있으며
구현자가 관심 있을 웹에서 문자열 : 언어 및 방향 메타 데이터 문서 [STRING-META]의
특정 부분을 강조하기 위해 구현되었다.
4.7.1 언어와 기본 방향
이 부분은 비규범적입니다.
데이터 퍼블리셔는 웹에서 문자열 : 언어 및 방향 메타 데이터 문서 [STRING-META]의
교차 구문 표현식 섹션을 읽고 [JSON-LD], [JSON] 및 CBOR [RFC7049]와 같이 여러 표현식 구문에서
언어 및 기본 방향 정보를 표현할 수 있도록 하는 것이 좋다.
일반적인 디자인 패턴은 언어 및 선택적으로 특정 기준 방향으로
태그가 지정된 텍스트 문자열을 표현할 때 다음 마크 업 템플릿을 사용하는 것이다.
"title": {
"value": "HTML و CSS: تصميم و إنشاء مواقع الويب",
"lang": "ar"
"dir": "rtl"
}
Note
많은 시스템에서 텍스트 문자열의 첫 번째 문자를 사용하여 텍스트 방향을 결정하므로
위의 텍스트는 언어와 방향을 명시적으로 표현하지 않고 왼쪽에서 오른쪽으로 잘못 표시된다.
JSON-LD를 사용하는 구현자는
국제화 된 속성을 정의하는 JSON-LD 컨텍스트를 extend하고
JSON-LD의 범위
지정된 컨텍스트 기능을 사용하여
@value, @language 및 @direction 키워드를
value, lang 및 dir로 별명
지정해야한다. 각기. 이를 수행하는 JSON-LD 컨텍스트 스니펫의 예는 다음과 같다.
여러 언어, 기본 방향 및 주석이 단일 자연 언어 문자열로 사용되는 경우
일반적으로 더 복잡한 메커니즘이 필요하다.
HTML과 같은 마크 업 언어를 사용하여 여러 언어와 기본 방향으로 텍스트를 인코딩 할 수 있다.
rdf : HTML 데이터 유형을 사용하여 이러한 값을 JSON-LD로 정확하게 인코딩 할 수도 있다.
정보를 HTML로 인코딩하는 기능에도 불구하고 구현자는 다음과 같은 이유로 이 작업을 수행하지 않는 것이 좋다.
일부 버전의 HTML 프로세서가 필요하므로 언어 및 기본 방향 정보 처리 부담이 증가한다.
HTML을 맹목적으로 처리하면 데이터 생성 프로세스 중 공격자가 어느 시점에 삽입 한
script 태그가 실행될 수 있으므로 이 데이터 모델을 사용할 때 보안 공격 영역이 증가한다.
구현자가 특정 사용 사례를 해결하기 위해
HTML 또는 실행 가능한 스크립트를 포함 할 수있는 다른 마크 업 언어를 사용해야한다고 생각하는 경우,
구현자는 공격자가 어떻게 마크 업을 사용하여 마크 업 소비자에 대한 인젝션 공격을 마운트 하는지 분석 후
식별된 공격에 대한 완화를 배포 한다.
4.8 검증
이 부분은 비규범적입니다.
이 사양은 검증 가능한 크리덴셜 또는 검증 가능한 프레젠테이션의 검증 프로세스에 대한 적합성 기준을
제공하지는 않지만 독자는 검증 과정에서 검증자가이 데이터 모델의 정보를 어떻게 활용할지 궁금 할 것이다.
이 섹션에서는 검증자가이 사양에서 예상되는 데이터 필드 사용과 관련하여 실무 그룹(working group)이 보유한
대화를 공유(capture)한다.
issuer속성에 대한 관련 메타 데이터가 검증자에게 제공 될 것으로 예상된다.
예를 들어, 발급자는 발급 한 검증 가능한 크리덴셜을 디지털 서명하는 데 사용하는 공개 키가
포함 된 정보를 게시 할 수 있다. 이 메타 데이터는 검증 가능한 크리덴셜에서 증명을 확인할 때 관련이 있다.
4.8.3 발급 날짜
이 부분은 비규범적입니다.
issuanceDate는 검증자의 예상 범위 내에 있어야한다.
예를 들어, 검증자는 검증 가능한 크리덴셜의 발급 날짜가 미래에 있지 않은지 확인할 수 있다.
4.8.4 Proofs (Signatures)
이 부분은 비규범적입니다.
The cryptographic mechanism used to prove that the information in a
verifiable credential or verifiable presentation was not
tampered with is called a proof. There are many types of cryptographic
proofs including, but not limited to, digital signatures, zero-knowledge proofs,
Proofs of Work, and Proofs of Stake. In general, when verifying proofs,
implementations are expected to ensure:
The proof is available in the form of a known proof suite.
The proof suite verification algorithm, when applied to the data, results
in an acceptable proof.
Some proofs are digital signatures. In general, when verifying digital
signatures, implementations are expected to ensure:
Acceptably recent metadata regarding the public key associated with the
signature is available. For example, the metadata might include
properties related to expiration, key owner, or key purpose.
The key is not suspended, revoked, or expired.
The cryptographic signature is expected to verify.
If the cryptographic suite expects a proofPurposeproperty,
it is expected to exist and be a valid value, such as
assertionMethod.
Note
The digital signature provides a number of protections, other than tamper
resistance, which are not immediately obvious. For example, a Linked Data
Signature createdproperty establishes a date and time
before which the credential should not be considered verified. The
verificationMethodproperty specifies, for example, the
public key that can be used to verify the digital signature. Dereferencing a
public key URL reveals information about the controller of the key, which can
be checked against the issuer of the credential. The
proofPurposeproperty clearly expresses the purpose for
the proof and ensures this information is protected by the signature. A proof is
typically attached to a verifiable presentation for authentication
purposes and to a verifiable credential as a method of assertion.
4.8.5 Expiration
이 부분은 비규범적입니다.
The expirationDate is expected to be within an expected range
for the verifier. For example, a verifier can check that the
expiration date of a verifiable credential is not in the past.
Fitness for purpose is about whether the custom properties in the
verifiable credential are appropriate for the verifier's purpose.
For example, if a verifier needs to determine whether a subject is
older than 21 years of age, they might rely on a specific birthdateproperty, or on more abstract properties, such as
ageOver.
The issuer is trusted by the verifier to make the claims at
hand. For example, a franchised fast food restaurant location trusts the
discount coupon claims made by the corporate headquarters of the
franchise. Policy information expressed by the issuer in the
verifiable credential should be respected by holders and
verifiers unless they accept the liability of ignoring the policy.
The order of the actions above is not fixed,
and some actions might be taken more than once. Such
action-recurrence might be immediate or at any later
point.
The most comon sequence of actions is envisioned to
be:
This specification does not define any protocol for
transfering verifiable credentials
or verifiable
presentations, but assuming other specifications do
specify how they are transferred between entities, then this
Verifiable Credential Data Model is directly applicable.
Have been transmitted in a way clearly establishing
that the issuer generated the
verifiable
credential and that the verifiable credential was
not tampered with in transit or storage. This trust
could be weakened depending on the risk assessment of
the verifier.
The holder trusts the repository to store
credentials securely, to not release them to anyone
other than the holder, and to not corrupt or
lose them while they are in its care.
This trust model differentiates itself from other trust
models by ensuring the:
By decoupling the trust between the identity provider and the relying party a more flexible and dynamic trust
model is created such that market competition and customer
choice is increased.
For more information about how this trust model interacts
with various threat models studied by the Working Group, see
the Verifiable Credentials Use Cases document
[VC-USECASES].
Note
Note
The data model detailed in this specification
does not imply a transitive trust model, such as that
provided by more traditional Certificate Authority trust
models. In the Verifiable Credentials Data Model, a
verifier either directly trusts or does not trust
an issuer. While it is possible to
build transitive trust models using the Verifiable
Credentials Data Model, implementers are urged to
learn about the security weaknesses introduced by
broadly delegating trust in the manner adopted by
Certificate Authority systems.
5.3
확장성
One of the goals of the Verifiable Credentials Data Model
is to enable permissionless innovation. To achieve this, the
data model needs to be extensible in a number of different
ways. The data model is required to:
Model complex multi-entity relationships through the
use of a graph-based data model.
Extend the machine-readable vocabularies used to
describe information in the data model, without the use of
a centralized system for doing so, through the use of
[LINKED-DATA].
Support multiple types of cryptographic proof formats
through the use of Linked Data Proofs [LD-PROOFS], Linked Data
Signatures [LD-SIGNATURES], and a
variety of signature suites.
Provide all of the extensibility mechanisms outlined
above in a data format that is popular with software
developers and web page authors, and is enabled through the
use of [JSON-LD].
This approach to data modeling is often called an open
world assumption, meaning that any entity can say
anything about any other entity. While this approach seems to
conflict with building simple and predictable software
systems, balancing extensibility with program correctness is
always more challenging with an open world assumption than
with closed software systems.
The rest of this section describes, through a series of
examples, how both extensibility and program correctness are
achieved.
This verifiable credential
states that the entity associated with
did:example:abcdef1234567 has a
name with a value of Jane Doe.
Now let us assume a developer wants to extend the verifiable credential to store two
additional pieces of information: an internal corporate
reference number, and Jane's favorite food.
The first thing to do is to create a JSON-LD context
containing two new terms, as shown below.
After this JSON-LD context is created, the developer
publishes it somewhere so it is accessible to verifiers who will be processing the verifiable credential. Assuming the
above JSON-LD context is published at
https://example.com/contexts/mycontext.jsonld,
we can extend this example by including the context and
adding the new properties and credentialtype to the verifiable credential.
Example 17: A
verifiable credential with a custom extension
This example demonstrates extending the Verifiable
Credentials Data Model in a permissionless and decentralized
way. The mechanism shown also ensures that verifiable credentials created in
this way provide a mechanism to prevent namespace conflicts
and semantic ambiguity.
A dynamic extensibility model such as this does increase
the implementation burden. Software written for such a system
has to determine whether verifiable credentials with
extensions are acceptable based on the risk profile of the
application. Some applications might accept only certain
extensions while highly secure environments might not accept
any extensions. These decisions are up to the developers of
these applications and are specifically not the domain of
this specification.
Developers are urged to ensure that extension JSON-LD
contexts are highly available. Implementations that cannot
fetch a context will produce an error. Strategies for
ensuring that extension JSON-LD contexts are always available
include using content-addressed URLs for contexts, bundling
context documents with implementations, or enabling
aggressive caching of contexts.
Implementers are advised to pay close attention to the
extension points in this specification, such as in Sections
§ 4.7 Proofs
(Signatures), § 4.9 Status,
§ 5.4 ,§ 5.5
Refreshing, § 5.6 Terms of
Use, and § 5.7 Evidence.
While this specification does not define concrete
implementations for those extension points, the Verifiable
Credentials Extension Registry [VC-EXTENSION-REGISTRY] provides an
unofficial, curated list of extensions that developers can
use from these extension points.
5.3.1 Semantic Interoperability
본 규격은 JSON-LD 프로세서를 사용하기 위한 JSON 구현의 필요 없이 전통적인 JSON 과 JSON-LD의 문법이 의미적으로 호환되도록 보장한다. 이를 달성하기 위해서, 규격은 다음의 추가적인 요구사항을 양쪽 모두의 문법에 부과한다:
JSON 기반의 프로세서는 반드시 @context 키를 처리해야 한다.
크리덴셜 타입이 처리되기 위해서는 기대되는 값들이 기대되는 순서로 존재하는 것이 보장되어야 하기 때문이다. type being processed.
그 순서가 중요하다. 크레덴션에 사용된 키들은 @context와 관련된 값들을 이용하여 정의되고, “먼저 정의된 것이 이기는” 메커니즘에 의하여 정의되기 때문에 순서를 바꾸는 것은 다른 정의가 “이기는” 결과를 초래한다.
JSON-LD 컨텍스트가 액티브 컨텍스트
안의 term을 재정의할 경우 JSON-LD 기반의 프로세서들은 반드시 에러를 생성해야 한다. 기존 term들의 정의를 변경하는 유일한 방법은
새로운 term을 도입하여 새로운 term의 스코프 내에서 액티브 컨텍스트를 지우는 것이다.
이 기능에 대한 자세한 설명은 JSON-LD 1.1 규격의 @protected 기능을 참조.
@context속성의 값 순서를 기술하는 문서는 상호운용성을 추구하는 구현자에 의하여
게시되어야 한다. 기계가 읽을 수 있는 설명(즉, 일반 JSON-LD 컨텍스트 문서)는 상호
운용성을 추구하는 JSON-LD 구현자가@context속성에 지정된 URL에 게시해야 한다.
위의 요구사항은@context 메커니즘에 의해 정의된 term에 대해 JSON과
JSON-LD 간의 의미론적 상호운용성을 보장한다. JSON-LD 프로세서가 특정 메커니즘을
사용하여 모든 term이 올바르게 지정되었는지 확인할 수 있는 반면, JSON 기반 프로세서는
term들이 올바르게 지정되었는지 확인하는 테스트 없이 암시적으로 동일한 term들의 집합을
수용한다. 즉, 데이터 교환이 발생하는 컨텍스트는 동일한 메커니즘을 사용하여 JSON과
JSON-LD 모두에서 명시적으로 선언된다. 이것이 JSON 기반 프로세서에서는 JSON-LD 처리
라이브러리를 사용할 필요없이 간단한 방식으로 달성된다.
5.4 데이터 스키마
데이터 스키마는 주어진 데이터 컬렉션에 특정 구조를 적용할 때 유용하다.
이 규격에서는 고려하는 데이터 스키마 유형은 최소 두 가지가 있다:
credentialSchemaproperty의 값은 반드시 제공된 데이터가 제공된 스키마와 일치하는지
판별하기에 충분한 정보를 검증자에게 제공하는 하나 이상의 데이터
스키마여야 한다. 각각의 credentialSchema은 반드시 그것의 타입을 지정
해야 한다. (예: JsonSchemaValidator2018).
credentialSchema의 id속성은 반드시 be a URI여야 한다. 각 데이터 스키마의 정확한
내용은 구체적인 타입 정의에 의해 결정된다.
Note
credentialSchema속성은 타입 정의에 주석을 달거나 특정 버전의 용어에
고정할 수 있게 한다. 검증 가능한 크리덴셜
의 작성자는 일부 콘텐츠 무결성 보호 메커니즘에 고정된
credentialSchema을 사용하여 정적 버전의 용어를 포함할
수 있다. credentialSchema속성을 사용하면
크리덴셜에 대해 구문 검사를 수행하고 JSON 스키마
[JSON-SCHEMA-2018] 유효성 검사와 같은
검증
메커니즘을 사용할 수 있다.
예시 18:
JSON 스키마 유효성 검사을 수행하기 위한 credentialSchema 속성의 사용
위의 예에서 발급자는 영지식 증명용으로 패키징된
이진 데이터 형식을 가리키는 credentialSchema를
지정한다. 이 이진 데이터 형식은 입력 데이터를 verifier가 이용할 수
있는 형식으로 변환할 수 있는데, 검증자는 변환된 데이터 형식을 이용하여
verifiable credential과 함께 제공된 증명의
유효성을 확인할 수 있다.
5.5 리프레싱
만료된 검증 가능한 크리덴셜을
수동 또는 자동으로 리프레시할 수 있게 하는 것은 시스템에 유용하다. 만료된 검증 가능한 크리덴셜에 대한 더 자세한 정보는
섹션 § 4.8 만료에서 기술한다. 이 규격은 발급자가 리프레시
서비스에 대한 링크를 포함할 수 있도록 refreshService속성
을 정의한다.
리프레시 서비스는 크리덴셜이 만료되었거나 발급자가 크리덴셜
상태 정보를 게시하지 않은 경우에만 사용되어야 한다. 공개된 정보를
포함하지 않거나 리프레시 서비스가 어떤 식으로든 보호되지 않는
검증 가능한 크리덴셜 에 refreshService속성을 넣는 것은 발급자에게 권장되지 않는다.
refreshServiceproperty의 값은 수신자가 검증 가능한 크리덴셜을 리프레시 할 수
있도록 반드시 수신자의
소프트웨어에 충분한 정보를 제공하는 하나 이상의 리프레시 서비스여야 한다.
각각의 refreshService 값은 필수적으로 specify its 타입
(예: ManualRefreshService2018)과 서비스의 URI인
id를 지정해야 한다. 각 리프레시 서비스의 자세한 내용은
특정 refreshService의 타입 정의에 의해 결정된다.
The value of the termsOfUseproperty tells the verifier what actions
it is required to perform (an obligation), not
allowed to perform (a prohibition), or allowed to
perform (a permission) if it is to accept the
verifiable credential or verifiable presentation.
The value of the termsOfUsepropertyMUST specify one or more terms of use
policies under which the creator issued the credential or presentation. If the recipient (a holder or verifier) is not
willing to adhere to the specified terms of use, then
they do so on their own responsibility and might incur
legal liability if they violate the stated terms of use.
Each termsOfUse value MUST specify its type, for
example, IssuerPolicy, and MAY specify its instance
id. The precise contents of each term of use
is determined by the specific termsOfUsetype definition.
Example 21:
Usage of the termsOfUse property by an issuer
In the example above, the holder (the
assigner), who is also the subject, expressed a term of use prohibiting the
verifier (the assignee,
https://wineonline.example.org) from using the
information provided to correlate the holder or
subject using a third-party service. If the
verifier were to use a third-party service for
correlation, they would violate the terms under which the
holder created the presentation.
This feature is also 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 usage of sensitive data.
Similarly, some verifiable credentials
issued by private industry are expected to limit usage to
within departments inside the organization, or during
business hours. Implementers are urged to read more about
this rapidly evolving feature in the appropriate section of
the Verifiable Credentials Implementation Guidelines
[VC-IMP-GUIDE]
document.
5.7 5.7
Evidence
Evidence can be included by an issuer to
provide the verifier with additional supporting
information in a verifiable credential.
This could be used by the verifier to establish
the confidence with which it relies on the claims in the
verifiable credential.
For example, an issuer could check physical
documentation provided by the subject or perform a
set of background checks before issuing the credential. In certain scenarios, this information
is useful to the verifier when determining the risk
associated with relying on a given credential.
This specification defines the evidenceproperty for expressing evidence information.
evidence
The value of the evidencepropertyMUST be one or more evidence schemes
providing enough information for a verifier to determine whether the evidence
gathered by the issuer meets its
confidence requirements for relying on the credential. Each evidence scheme is identified
by its type. The idproperty is optional, but if
present, SHOULD
contain a URL that points to where more information about
this instance of evidence can be found. The precise
content of each evidence scheme is determined by the
specific evidencetype definition.
Note
Note
For information about how attachments and
references to credentials and non-credential
data might be supported by the specification, see the
Verifiable Credentials Implementation Guidelines
[VC-IMP-GUIDE]
document.
The evidenceproperty provides different and complementary
information to the proofproperty. The evidenceproperty is used to express supporting
information, such as documentary evidence, related to the
integrity of the verifiable
credential. In contrast, the proofproperty 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 the proofproperty, see Section § 4.7 Proofs (Signatures).
5.8 5.8 Zero-Knowledge Proofs
A zero-knowledge proof is a cryptographic method where an
entity can prove to another entity that they know a certain
value without disclosing the actual value. A real-world
example is proving that an accredited university has granted
a degree to you without revealing your identity or any other
personally identifiable information contained on the
degree.
The key capabilities introduced by zero-knowledge proof
mechanisms are the ability of a holder to:
This specification describes a data model that supports
zero-knowledge proof mechanisms. The examples below highlight
how the data model can be used to issue, present, and verify
zero-knowledge verifiable
credentials.
To use zero-knowledge verifiable credentials the issuer must issue a verifiable credential in a manner
that enables the holder to present the information to
a verifier in a privacy-enhancing manner. This
implies that the holder can prove the validity of the
issuer's signature without revealing the values
that were signed, or when only revealing certain selected
values. The standard practice is to do so by proving
knowledge of the signature, without revealing the signature
itself. There are two requirements for verifiable credentials when they are
to be used in zero-knowledge proof systems. The verifiable credentialMUST contain a:
Credential definition, using the
credentialSchemaproperty,
that can be used by all parties to perform various
cryptographic operations in zero-knowledge.
The following example shows one method of using verifiable credentials in
zero-knowledge. It makes use of a CL Signature, which allows
the presentation of the verifiable
credential in a way that supports the privacy of the
holder and subject through the
use of selective disclosure of the verifiable credential values.
Example 24: A
verifiable credential that supports CL Signatures
The example above provides the verifiable credential definition by
using the credentialSchemaproperty and a specific proof that is usable in the
Camenisch-Lysyanskaya Zero-Knowledge Proof system.
그림 14
Figure 11 A visual example of the relationship between
credentials and derived credentials in a ZKP presentation.
Note
Note
Important details regarding the format for the
credential definition and of the
proofs are omitted on purpose because they are outside of
the scope of this document. The purpose of this section is
to guide implementers who want to extend verifiable credentials and
verifiable presentations to
support zero-knowledge proof systems.
5.9 5.9
Disputes
There are at least two different cases to consider for an
entity wanting to dispute a credential issued by an issuer:
A subject disputes a claim made by
the issuer. For example, the
addressproperty is
incorrect or out of date.
An entity disputes a potentially
false claim made by the issuer about a
different subject. For example, an imposter
claims the social security number for an entity.
The mechanism for issuing a DisputeCredential
is the same as for a regular credential except that
the credentialSubject identifier in the
DisputeCredentialproperty is the
identifier of the disputed credential.
For example, if a credential with an
identifier of
https://example.org/credentials/245 is disputed,
the subject can issue the credential shown below and present it to the
verifier along with the disputed credential.
If a credential does not
have an identifier, a content-addressed identifier can be
used to identify the disputed credential.
Similarly, content-addressed identifiers can be used to
uniquely identify individual claims.
Note
Note
This area of study is rapidly evolving and
developers that are interested in publishing credentials that dispute the veracity of other
credentials are urged to read the
section related to disputes in the Verifiable Credentials
Implementation Guidelines [VC-IMP-GUIDE]
document.
5.10 5.10
Authorization
이 부분은 비규범적입니다.
This section is non-normative.
Verifiable credentials are intended
as a means of reliably identifying subjects. While
it is recognized that Role Based Access Controls (RBACs) and
Attribute Based Access Controls (ABACs) rely on this
identification as a means of authorizing subjects to access resources, this specification
does not provide a complete solution for RBAC or ABAC.
Authorization is not an appropriate use for this
specification without an accompanying authorization
framework.
The Working Group did consider authorization use cases
during the creation of this specification and is pursuing
that work as an architectural layer built on top of this
specification.
A. Base Context
이 부분은 비규범적입니다.
The base context, located at
https://www.w3.org/2018/credentials/v1 with a SHA-256 digest of
ab4ddd9a531758807a79a5b450510d61ae8d147eab966cc9a200c07095b0cdcc,
can be used to implement a local cached copy. For convenience, the base context
is also provided in this section.
This section describes possible relationships between a subject and a
holder and how the Verifiable Credentials Data Model expresses these
relationships. The following diagram illustrates these relationships, with the
subsequent sections describing how each of these relationships are handled in
the data model.
그림 15
Subject-Holder Relationships in Verifiable Credentials.
In this case, the credentialSubjectproperty might contain
multiple properties, each providing an aspect of a description of the
subject, which combine together to unambiguously identify the
subject. Some use cases might not require the holder to be
identified at all, such as checking to see if a doctor (the subject) is
board-certified. Other use cases might require the verifier to use
out-of-band knowledge to determine the relationship between the subject
and the holder.
예시 41: A credential uniquely identifying a subject
The mechanisms listed above describe the relationship between the
holder and the subject and helps the verifier decide
whether the relationship is sufficiently expressed for a given use case.
Note
The additional mechanisms the issuer or the verifier uses to
verify the relationship between the subject and the holder are
outside the scope of this specification.
예시 42: The relationship property in a child's credential
In the example above, the issuer expresses the relationship between the
child and the parent such that a verifier would most likely accept the
credential if it is provided by the child or the parent.
예시 43: A relationship credential issued to a parent
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "RelationshipCredential"],
"issuer": "https://example.edu/issuers/14",
"issuanceDate": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1c276e12ec211f712ebc6f",
"child": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"type": "Child"
}
},
"proof": { ... } // the proof is generated by the DMV
}
In the example above, the issuer expresses the relationship between the
child and the parent in a separate credential such that a
verifier would most likely accept any of the child's credentials
if they are provided by the child or if the credential above is
provided with any of the child's credentials.
예시 44: A relationship credential issued by a child
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.org/credentials/23894",
"type": ["VerifiableCredential", "RelationshipCredential"],
"issuer": "http://example.org/credentials/23894",
"issuanceDate": "2010-01-01T19:23:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"parent": {
"id": "did:example:ebfeb1c276e12ec211f712ebc6f",
"type": "Mother"
}
},
"proof": { ... } // the proof is generated by the child
}
In the example above, the child expresses the relationship between the child and
the parent in a separate credential such that a verifier would
most likely accept any of the child's credentials if the
credential above is provided.
Similarly, the strategies described in the examples above can be used for many
other types of use cases, including power of attorney, pet ownership, and
patient prescription pickup.
B.5 Subject Passes a Verifiable Credential to Someone Else
Verifiable credentials are not an authorization framework and therefore
delegation is outside the scope of this specification. However, it is understood
that verifiable credentials are likely to be used to build authorization and
delegation systems. The following is one approach that might be appropriate for
some use cases.
예시 46: A credential issued to a
holder who is not the (only) subject of the credential, who has no relationship with
the subject of the credential, but who has a relationship with the issuer
B.7 Holder Acts on Behalf of the Verifier, or has no Relationship with
the Subject, Issuer, or Verifier
이 부분은 비규범적입니다.
The Verifiable Credentials Data Model currently does not support either of
these scenarios. It is for further study how they might be supported.
C. IANA Considerations
이 부분은 비규범적입니다.
This section will be submitted to the Internet Engineering Steering Group
(IESG) for review, approval, and registration with IANA in the
"JSON Web Token Claims Registry".
The Working Group would like to thank the following individuals for reviewing
and providing feedback on the specification (in alphabetical order):
Christopher Allen, David Ammouial, Joe Andrieu, Bohdan Andriyiv, Ganesh
Annan, Kazuyuki Ashimura, Tim Bouma, Pelle Braendgaard, Dan Brickley,
Allen Brown, Jeff Burdges, Daniel Burnett, ckennedy422, David Chadwick,
Chaoxinhu, Kim (Hamilton) Duffy, Lautaro Dragan, enuoCM, Ken Ebert, Eric
Elliott, William Entriken, David Ezell, Nathan George, Reto Gmür, Ryan
Grant, glauserr, Adrian Gropper, Joel Gustafson, Amy Guy, Lovesh
Harchandani, Daniel Hardman, Dominique Hazael-Massieux, Jonathan Holt,
David Hyland-Wood, Iso5786, Renato Iannella, Richard Ishida, Ian Jacobs,
Anil John, Tom Jones, Rieks Joosten, Gregg Kellogg, Kevin, Eric Korb,
David I. Lehn, Michael Lodder, Dave Longley, Christian Lundkvist, Jim
Masloski, Pat McBennett, Adam C. Migus, Liam Missin, Alexander Mühle,
Anthony Nadalin, Clare Nelson, Mircea Nistor, Grant Noble, Darrell
O'Donnell, Nate Otto, Matt Peterson, Addison Phillips, Eric Prud'hommeaux,
Liam Quin, Rajesh Rathnam, Drummond Reed, Yancy Ribbens, Justin Richer,
Evstifeev Roman, RorschachRev, Steven Rowat, Pete Rowley, Markus
Sabadello, Kristijan Sedlak, Tzviya Seigman, Reza Soltani, Manu Sporny,
Orie Steele, Matt Stone, Oliver Terbu, Ted Thibodeau Jr, John Tibbetts,
Mike Varley, Richard Varn, Heather Vescent, Christopher Lemmer Webber,
Benjamin Young, Kaliya Young, Dmitri Zagidulin, and Brent Zundel.
