diff --git a/diagrams/claim-extended.svg b/diagrams/claim-extended.svg index 89623e7cb..e1d2ced50 100644 --- a/diagrams/claim-extended.svg +++ b/diagrams/claim-extended.svg @@ -1,4 +1,4 @@ - + diff --git a/index.html b/index.html index b938877a9..e57ce5308 100644 --- a/index.html +++ b/index.html @@ -132,7 +132,7 @@

Introduction

Granting a benefit requires proof and verification. Some benefits demand a formal process that includes three parties. In this process, -the holder asks for the benefit and the inspector-verifier +the holder asks for the benefit and the verifier grants or denies the benefit based on verification of the holder’s qualification from a trusted issuer.

@@ -212,10 +212,10 @@

Ecosystem Overview

with a particular subject, and transmits it to a holder. Examples of issuers include corporations, governments, and individuals. -
inspector-verifier
+
verifier
An entity that receives one or more verifiable claims for -processing. Examples of inspector-verifiers include employers, security personnel, and +processing. Examples of verifiers include employers, security personnel, and websites.
identifier registry
@@ -282,12 +282,12 @@

Use Cases and Requirements

issuers through an agent that the issuer does not need to trust.
  • -Holders SHOULD be positioned between issuers and inspector-verifiers +Holders SHOULD be positioned between issuers and verifiers and mediate the transmission of verifiable claims.
  • -Holders MUST provide verifiable claims to inspector-verifiers -through an agent that inspector-verifiers needn't trust; they only need to trust +Holders MUST provide verifiable claims to verifiers +through an agent that verifiers needn't trust; they only need to trust issuers.
  • @@ -307,7 +307,7 @@

    Use Cases and Requirements

  • Holders that share verifiable claims MUST NOT be required to -reveal the identity of the inspector-verifier to issuers. +reveal the identity of the verifier to issuers.
  • A verifiable claim MUST be expressed in one or more standard, @@ -397,7 +397,7 @@

    Claims

    These claims may be merged together to express a graph of information about a particular subject. The example below extends the data model above by adding claims that state that Pat knows Sam and that -Sam is a student. +Sam is employed as a professor.

    @@ -508,7 +508,7 @@

    Verifiable Profile Model

    the Verifiable Profile Model are merely information that, together with a subject identifier id, - constitute an verifiable profile. The properties are not claims + constitute a verifiable profile. The properties are not claims and are not intended to be verifiable.

    The following properties are required in the Entity Profile Model:

    @@ -774,7 +774,7 @@

    Evidence

    evidence
    The value of this property MUST be one or more evidence schemes - that provides enough information to a inspector-verifier + that provides enough information to a verifier to determine whether or not the evidence gathered meets their requirements.
    @@ -853,7 +853,7 @@

    Subject

    Likely, that means it is the id of a known and trusted verifiable profile for the subject of the claim. If the entity that is subject of a claim has transmitted it to the - inspector-verifier, the subject may be able to prove ownership of key + verifier, the subject may be able to prove ownership of key identifying properties such as email address(es) and public key(s).
  • @@ -878,7 +878,7 @@

    Signature

    Expiration

    @@ -893,21 +893,21 @@

    Revocation

    Fitness for Purpose

    @@ -1197,8 +1197,8 @@

    Verifiable Credential

    itself, such as an identifier for the entity that issued it and a date for when it was issued.

    -
    {
    -  "@context": "https://w3id.org/identity/v1",
    +
    {
    +  "@context": "https://w3id.org/credentials/v1",
       "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
       "ageOver": 21
     }
    @@ -1209,11 +1209,8 @@

    Verifiable Credential

    a signature that can be used to verify its entire contents, including the claim.

    -
    {
    -  "@context": [
    -    "https://w3id.org/identity/v1",
    -    "https://w3id.org/security/v1"
    -  ],
    +
    {
    +  "@context": "https://w3id.org/credentials/v1",
       "id": "http://example.gov/credentials/3732",
       "type": ["Credential", "ProofOfAgeCredential"],
       "issuer": "https://dmv.example.gov",
    @@ -1237,10 +1234,10 @@ 

    Verifiable Credential

    of verifiable claims about a particular subject.

    -
    {
    +
    {
       "@context": [
    -    "https://w3id.org/identity/v1",
    -    "https://w3id.org/security/v1"
    +    "http://schema.org",
    +    "https://w3id.org/credentials/v1"
       ],
       "id": "http://example.gov/credentials/3732",
       "type": ["Credential", "PassportCredential"],
    @@ -1299,10 +1296,10 @@ 

    Verifiable Profile

    The following example demonstrates how to express a simple verifiable profile.

    -
    {
    +
    {
       "@context": [
    -    "https://w3id.org/identity/v1",
    -    "https://w3id.org/security/v1"
    +    "http://schema.org",
    +    "https://w3id.org/credentials/v1"
       ],
       "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
       "credential": [{
    @@ -1690,7 +1687,7 @@ 

    Personally Identifiable Information

    The data associated with verifiable claims stored in the credential.claim field are largely susceptible to privacy -violations when shared with Inspector-verifiers. Personally identifying data +violations when shared with Verifiers. Personally identifying data such as a government-issued identifier, shipping address, and full name can be easily used to determine, track, and correlate an entity. Even information that does not seem personally identifiable like the @@ -1703,7 +1700,7 @@

    Personally Identifiable Information

    warn Holders when they share data with these sorts of characteristics. Issuers are strongly advised to provide privacy-protecting credentials when possible. For example, issuing ageOver credentials instead of -birthdate credentials when the Inspector-verifier desires to determine if an +birthdate credentials when the Verifier desires to determine if an entity is over the age of 18.

    @@ -1772,7 +1769,7 @@

    Favor Abstract Claims

    In order to enable recipients of verifiable claims to use them in a variety of circumstances without revealing more personally identifiable information than necessary for the transaction, issuers should consider limiting the information published in a claim to a minimal set needed for the expected purposes. -One way to avoid placing personally identifiable information in a claim is to use an "abstract" property that meets the needs of inspector-verifiers without providing specific information about the subject. +One way to avoid placing personally identifiable information in a claim is to use an "abstract" property that meets the needs of verifiers without providing specific information about the subject.

    An example in this document is the use of the ageOver property as opposed to a specific birthdate that would constitute much stronger personally identifiable information. @@ -1793,8 +1790,8 @@

    The Principle of Minimum Disclosure

    With verifiable claims, minimal disclosure for issuers means limiting the -content of a claim to the minimum required by potential inspector-verifiers for -expected use. For inspector-verifiers, it means limiting the scope of claims +content of a claim to the minimum required by potential verifiers for +expected use. For verifiers, it means limiting the scope of claims request or required for accessing services.

    @@ -1818,9 +1815,9 @@

    The Principle of Minimum Disclosure

    issue such claims.

    -Similarly, inspector-verifiers are urged to only request information that is absolutely +Similarly, verifiers are urged to only request information that is absolutely necessary for a particular transaction to occur. This is important for at -least two reasons: 1) it reduces the liability on the inspector-verifier for +least two reasons: 1) it reduces the liability on the verifier for handling highly sensitive information that it does not need, and 2) it enhances the privacy of the individual by only asking for information that is required for the particular transaction. @@ -1840,7 +1837,7 @@

    Bearer Claims

    Validity Checks

    -Inspector-verifier (corporation) is required to check revocation via Issuer +Verifier (corporation) is required to check revocation via Issuer (government).

    @@ -1904,30 +1901,30 @@

    Usage Patterns

    1. -When the same claim is presented to the same inspector-verifier more than once – -that inspector-verifier could infer that the holder is the same individual. +When the same claim is presented to the same verifier more than once – +that verifier could infer that the holder is the same individual.
    2. -When the same claim is presented to different inspector-verifiers, and either those -inspector-verifiers collude or a third party has access to transaction records from -both inspector-verifiers – the observant party could infer that the individual +When the same claim is presented to different verifiers, and either those +verifiers collude or a third party has access to transaction records from +both verifiers – the observant party could infer that the individual presenting the claims is the same person at both services, i.e., the accounts are controlled by the same person.
    3. When the same subject identifier of a claim refers to the same subject across -presentations or inspector-verifiers. Even when different claims are presented, -if the subject identifier is the same, inspector-verifiers (and those with access to -inspector-verifier logs) could infer that the holder of the claims is the same +presentations or verifiers. Even when different claims are presented, +if the subject identifier is the same, verifiers (and those with access to +verifier logs) could infer that the holder of the claims is the same person.
    4. When the underlying information in a claim can be used to identify an individual across services – using information from other sources -(including information provided directly by the user), inspector-verifiers can use +(including information provided directly by the user), verifiers can use the information inside the claim to correlate the individual with an existing profile. For example, if a holder presents claims that include -zip code, age, and sex, the inspector-verifier can potentially correlate the +zip code, age, and sex, the verifier can potentially correlate the subject of that claim with an established profile [see Sweeney 2000 Simple Demographics Often Identify People Uniquely].
    5. @@ -2051,7 +2048,7 @@

      Bundling Dependent Claims

      each containing one of the following properties: "Staff Member", "Post Graduate Student", "Department of Computing" and "Department of Economics". The holder could then transfer -the "Staff Member" and "Department of Economics" to an inspector-verifier, +the "Staff Member" and "Department of Economics" to a verifier, which together would comprise a false claim.