|
The original Call For Participation for this TC may be found at https://lists.oasis-open.org/archives/members/202305/msg00000.html
Contents
(1)(a) TC Name
Lightweight Verifiable Credential Schema and Process (LVCSP)
(1)(b) Statement of Purpose
This TC aims to define a lightweight identity credential schema, based on the W3C Verifiable Credential (VC) standard, to enable individuals (VC subjects) to share their verified identity attestations across different platforms and services.
This work assumes the following operational pattern: a) an issuer issues a VC that asserts the VC subject has passed checks of a defined business process (such as Know Your Customer, or KYC); b) the VC subject can then present the assertion to a Relying Party (RP). The goal of explicitly defining this pattern as a reusable schema template is to encourage alignment among issuers, thereby, improving interoperability and portability for subjects and relying parties.
This pattern has been applied to a range of use cases including those requiring minimal personally identifiable information (PII), while also enabling composability when more personal data is required.
It is possible for a VC issuer to issue a credential with variable assurance levels. The assurance levels are a function of required checks that are performed based on some acceptance criteria as determined by an RP. The RP could be a regulated entity that must adhere to strict compliance rules. As such, the RP could restrict the acceptance of a VC to selected issuers that are deemed trustworthy to the RP. This can be implemented through a governance framework. The VC Schema can be used by an issuer and/or RP to quickly and securely identify assurance levels as presented in the VC.
Starting with the minimal PII side of the spectrum, examples include:
-
A VC issuer issues a credential attesting that the VC subject has passed its KYC checks according to the United States jurisdiction, but does not include details of the checks (e.g., names, addresses, etc. are omitted ). A relying party may choose to accept this credential based on trust in the issuer’s processes.
-
The following are structurally similar to above with the specific business process replaced, e.g.:
a. The subject is an accredited investor according to a defined process;
b. The subject has passed KYB (Know your Business) checks according to a defined process.
Beginning with this simple baseline, additional claims may be composed to fit use cases where more detail is required:
-
The relying party requires multiple of the above type of credentials, e.g., a KYB and an Accredited Investor credential;
-
The relying party requires some other identity assurance, e.g., in addition to a KYC credential, the RP also requires evidence that the credential subject is also not a resident of New York.
Note: Composable extensions may be issued in multiple ways (same issuer/VC/subject identifier; different ones [JS2] ) which result in different identity assurance considerations. These considerations will be described as informative (not normative) output of this TC.
Reuse of verified identity claims in this manner can promote efficiency in customer onboarding and reduce proliferation of sensitive personal data where it is not needed. This is in contrast to current customer onboarding processes, where individuals typically reshare identity attributes for each new organization with whom they interact, introducing delays and expense for both the customer and onboarding organization.
Note: These use cases are governance agreements among all parties (issuers, RPs, VC subjects), especially in cases where involved parties are regulated entities. These considerations vary widely and are assumed to be out of scope but will be described as informative (not normative) output of this TC.
Auxiliary goals of this TC include:
-
Demonstrate patterns for reusable identity credentials that do not exacerbate proliferation of personal data when it is not needed. TC output will include informative examples of VCs containing minimal PII which may be used to achieve useful end-to-end scenarios.
-
Providing clarity on how composability via stackable claims relates to selective disclosure or zero knowledge techniques:
- Signature suites achieving such techniques require more diligence (standards maturity, library support, security testing) before they will be relied on at scale.
- The approach described here enables credentials that, by design, minimize the sensitive information that is shared.
Any entity involved in issuance or consumption of verifiable credentials referring to a defined business process will benefit from this work.
The stakeholders who will be impacted by this standard include:
-
VC subjects and RPs: improve efficiency and security, while reducing cost in onboarding
-
Issuers and verifiers: potential revenue source
Business Benefits
W3C Verifiable Credentials (VC) schema provides a specification for generating credentials that could be consumed by RP at scale. Standardizing on common schemas can help in the following area:
-
Enhanced Trust in the adopters ecosystem. A standardized schema for digital credentials can help businesses improve the security of online transactions. Improved security can reduce fraud and financial losses.
-
Enhanced Efficiency: The ability for RP to quickly and efficiently parse VC with known security assurance enables them to streamline online operations more easily, thus reducing the time and effort required to verify information and complete transactions.
-
Increased Interoperability: A standardized schema format allows businesses to integrate their systems and exchange information with other organizations, independent from their technical infrastructure or platform.
-
Reduced Costs: Interoperability resulting from a common VC Schema can reduce costs associated with managing many digital credentials within an RP.
-
Reduce user friction: Users will benefit since they can re-use the credential across many RP in a transparent fashion.
(1)(c) Scope
The Technical Committee (TC) is focused on defining key artifacts in support of operational patterns in which an issuer issues a VC asserting that the VC subject has passed checks of a defined business process. These artifacts include schemas, use cases, procedures, and recommendations, and are described in detail in “Deliverables” section
Where possible, the TC generally will rely on existing, widely used definitions and industry practices.
Additional Assumptions:
-
Each issuer chooses which credentials to issue,
-
Each credential issued refers specifically to the process definitions it used to arrive at those claims,
-
Each issuer can choose which kinds of environment (e.g., wallet, hub, etc) to issue these credentials into, based on technical and/or business criteria
-
Each holder can inspect these credentials and, with a little effort, understand them; nothing in them is opaque or proprietary
-
1-to-many relationship between credentials and processes
-
Each verifier can choose which issuers, which credentials, and which process definitions are adequate for a given use-case
The following work will be out of scope for the TC:
-
Definition of business processes or rulebooks associated with credential issuance
-
Normative definition of specific credentials (although informative examples will be included)
-
Mandates of specific cryptographic signature suites or specific issuer or subject identifier methods
-
Mandates of specific issuance or exchange protocols
-
Definition of specific governance frameworks or rules regarding credential use and liability
- Issuer accreditation is out of scope
-
Normative definition of ID binding methods (although informative examples may be included)
This work is designed to be compatible with established security standards such as the US National Institute of Standards and Technology (NIST) and the European eIDAS levels of assurance. The output will include informative discussion of how this approach addresses security and privacy assurance in line with established US NIST, European eIDAS, or other standard levels of assurance.
(1)(d) Deliverables
The LVCSP TC will create the following deliverables:
- A schema for a VC issued upon completion of an identity verification business process as follows:
- The VC will include or reference the business process (i.e., steps), but will not include the corresponding PII gathered in the process.
- Deliverable formats will include JSON schemas and JSON-LD contexts
- Assumes the issuer’s authorization to issue this credential under this process/framework (i.e., semantically corresponds to the authorization to issue)
- Informative examples of representative use cases
- (informative) example defined process
- (informative) issuer/RP semantics
- Including reliance and governance considerations
- (informative) verification procedure that an RP would follow, including subject authentication
- An informative description of how a relying party would verify integrity and authenticity of the VC.
- Security analysis of the supported schema
Where possible, the TC generally will rely on existing, widely used definitions and industry practices.
Other deliverables that fall within the scope of the project may be identified over time as the TC engages in its work.
The TC may re-factor the deliverables above as it sees fit into fewer, more, or differently combined documents. In any case, the deliverables shall:
- Be vendor-neutral and product-agnostic. (The TC may also elect to provide proof-of-concept instances but will strive to facilitate ease of implementation regardless of data schema choices.)
- To the extent feasible, re-use rather than re-invent suitable existing definitions of policy concepts such as identity tokens and personally identifiable data.
- Describe with specificity their application to established US NIST and European eIDAS levels of assurance.
(1)(e) IPR Mode
The TC will operate under the Non Assertion Terms mode of the OASIS IPR Policy.
(1)(f) Audience
The target audience of this TC are technical persons, developers, standard development people and any person that are involved in designing, implementing solutions that require verifiable credentials. Verifiable credentials are used in many areas including financial services, healthcare, travel, IoT, government, education, and refugee and vulnerable population use cases.
(1)(g) Language
The business of the TC will be conducted in English.
|
