OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

members message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Call for Participation: Proposed Charter for Lightweight Verifiable Credential Schema and Process (LVCSP)

To OASIS Members & Interested Parties:

A new OASIS technical committee is being formed. The Lightweight Verifiable Credential Schema and Process (LVCSP) Technical Committee has been proposed by the members of OASIS listed in the charter below. The TC name, statement of purpose, scope, list of deliverables, audience, IPR mode, and language specified in this proposal will constitute the TC's official charter. Submissions of technology for consideration by the TC and the beginning of technical discussions may occur no sooner than the TC's first meeting.

The eligibility requirements for becoming a participant in the TC at the first meeting are:

To be considered a voting member at the first meeting:

Participants may also join the TC at a later time. OASIS and the TC welcomes all interested parties.

Non-OASIS members who wish to participate may contact us about joining OASIS [b]. In addition, the public may access the information resources maintained for each TC: a mail list archive, document repository, and public comments facility, which will be linked from the TC's public home page at [c].

Please feel free to forward this announcement to any other appropriate lists. OASIS is an open standards organization; we encourage your participation.


[a] https://www.oasis-open.org/apps/org/workgroup/lvcsp

[b] See http://www.oasis-open.org/join/

[c] https://www.oasis-open.org/apps/org/workgroup/lvcsp



OASIS LVCSP Technical Committee Charter

The charter for this TC is as follows.

Section 1: TC Charter

(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:

1. 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.Â

2. 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:


  1. 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.

  2. 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.

  3. 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.

  4. Reduced Costs: Interoperability resulting from a common VC Schema can reduce costs associated with managing many digital credentials within an RP.

  5. 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.

(Optional References for Section 1)

Section 2: Additional Information

(2)(a) Identification of Similar Work

Related work, which will inform this effort:

(2)(b) First TC Meeting

The first TC meeting will be held June 8, 2023 at 10:30am ET.

(2)(c) Ongoing Meeting Schedule

The TC will meet on bi-weekly basis for 1 hour.

(2)(d) TC Proposers

Abbie Barbir, Aetna

Alan Bachman, Aetna

Hiroshi Takechi, NEC

Charlie Hart, Hitachi

Ori Eisen, Trusona

Bojan Simic, HYPR

Ryan Rowcliffe, HYPR

Spencer Yezo, HYPR

John Sabo, Individual Contributor

(2)(e) Primary Representatives' SupportÂ

I, Abbie Babrir, as OASIS primary representative for Aetna/CVS, confirm our support for the LVCSP TC and our participants listed above.

I, Ori Eisen, as OASIS primary representative for Trusona, confirm our support for the LVCSP TC and our participants listed above.

I, Bojan Simic, as OASIS primary representative for HYPR Corp., confirm our support for the LVCSP TC and our participants listed above.

I, Akihito Sawada, as OASIS primary representative for Hitachi Ltd., confirm our support for the LVCSP TC and our participants listed above.

I, Takahiro Kakumaru, as OASIS primary representative for NEC Corporation, confirm our support for the LVSP TC and our participants to this TC.

(2)(f) TC Convener

Abbie Barbir, Aetna/CVS, will serve as convener.


Kelly Cullinane

Technical Community Program StewardÂ



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]