To OASIS Members:
A draft TC charter has been submitted to establish the Lightweight Verifiable Credential Schema and Process (LVCSP) TC. In accordance with the OASIS TC Process Policy section 2.2: (https://www.oasis-open.org/policies-guidelines/tc-process#formation) the proposed charter is hereby submitted for comment. The comment period shall remain open until 23:59 GMT on 24 March 2023.
OASIS maintains a mailing list for the purpose of submitting comments on proposed charters. Any OASIS member may post to this list by sending an email to: oasis-charter-discuss@lists.oasis-open.org. All messages will be publicly archived at: http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members who wish to receive emails must join the group by selecting "join group" on the group home page: http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/. Employees of organizational members do not require primary representative approval to subscribe to the oasis-charter-discuss e-mail.
This call for comment is also available as a Google Doc. See https://docs.google.com/document/d/1rwArKAeQJB0CJ0uSN3ZGU1iuQ0YBJy7IjIfQhAFIAws/edit?usp=sharing. Comments and suggestions may be left on that document.
Comments received will be reviewed by the proposers and a log of the comments and their resolution will be posted to oasis-charter-discuss mailing list before the telephone call with the convener.
A telephone conference will be held among the Convener, the OASIS TC Administrator, and those proposers who wish to attend no more than four days after the comment period closes. The announcement and call-in information will be noted on the OASIS Charter Discuss Group Calendar.
We encourage member comments and ask that you note the name of the proposed TC (LVCSP TC) in the subject line of your email message. Comments received will be reviewed by the proposers and a log of the comments and their resolution will be posted to oasis-charter-discuss mailing list before the telephone call with the convener.
If you wish to be listed as a co-proposer in the Call for Participation, please contact the convener Abbie Barbir, BarbirA@cvshealth.com, no later than 23 March 2023. For representatives of OASIS organizational members, a statement of support from their Primary Representative will be required.
Thank you,
Kelly Â
--------------
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:
â ÂAn 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 TC will define a minimal schema representing âissuer asserts subject passed checks defined by processâ. The schema will:
â Provide a list of use cases
â Semantically correspond to the authorization to issue this credential under this process/framework
â The TC will demonstrate informative examples applied to specific use cases, including:
â (informative) example defined process
â (informative) issuer/RP semantics
â Including reliance and governance considerations
â (informative) verification procedure that an RP would follow, including subject authentication
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 wallets to issue these credentials into, based on technical and/or business criteria
â Each wallet-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 DID 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:
â Use case and summary of supported use cases
â A schema for a VC issued upon completion of an identity verification business process
â An informative description of how a relying party would verify integrity and authenticity of the VC.
â Security analysis of the supported schema
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
There is currently no work that will be identical to what this TC is trying to develop.
(2)(b) First TC Meeting
The first TC meeting will be held April 12, 2023, at 6 PM Eastern time.
(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
Kim Hamilton, Individual Contributor
Juan Caballero, Individual Contributor
Hiroshi Takashi (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 (BarbirA@cvshealth.com), as OASIS primary representative for Aetna/CVS, confirm our support for the LVCSP TC and our participants listed above.
I, Ori Eisen (o@trusona.com), 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 LVCSP TC and our participants to this TC.
(2)(f) TC Convener
Abbie Barbir, Aetna/CVS (abarbir@live.ca) will serve as convener
(2)(g) Anticipated Contributions
(2)(i) FAQ Document
(2)(j) Work Product Titles and Acronyms
-- A draft TC charter has been submitted to establish the Lightweight Verifiable Credential Schema and Process (LVCSP) TC. In accordance with the OASIS TC Process Policy section 2.2: (https://www.oasis-open.org/policies-guidelines/tc-process#formation) the proposed charter is hereby submitted for comment. The comment period shall remain open until 23:59 GMT on 24 March 2023.
OASIS maintains a mailing list for the purpose of submitting comments on proposed charters. Any OASIS member may post to this list by sending an email to: oasis-charter-discuss@lists.oasis-open.org. All messages will be publicly archived at: http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members who wish to receive emails must join the group by selecting "join group" on the group home page: http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/. Employees of organizational members do not require primary representative approval to subscribe to the oasis-charter-discuss e-mail.
This call for comment is also available as a Google Doc. See https://docs.google.com/document/d/1rwArKAeQJB0CJ0uSN3ZGU1iuQ0YBJy7IjIfQhAFIAws/edit?usp=sharing. Comments and suggestions may be left on that document.
Comments received will be reviewed by the proposers and a log of the comments and their resolution will be posted to oasis-charter-discuss mailing list before the telephone call with the convener.
A telephone conference will be held among the Convener, the OASIS TC Administrator, and those proposers who wish to attend no more than four days after the comment period closes. The announcement and call-in information will be noted on the OASIS Charter Discuss Group Calendar.
We encourage member comments and ask that you note the name of the proposed TC (LVCSP TC) in the subject line of your email message. Comments received will be reviewed by the proposers and a log of the comments and their resolution will be posted to oasis-charter-discuss mailing list before the telephone call with the convener.
If you wish to be listed as a co-proposer in the Call for Participation, please contact the convener Abbie Barbir, BarbirA@cvshealth.com, no later than 23 March 2023. For representatives of OASIS organizational members, a statement of support from their Primary Representative will be required.
Thank you,
Kelly Â
--------------
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:
â ÂAn 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 TC will define a minimal schema representing âissuer asserts subject passed checks defined by processâ. The schema will:
â Provide a list of use cases
â Semantically correspond to the authorization to issue this credential under this process/framework
â The TC will demonstrate informative examples applied to specific use cases, including:
â (informative) example defined process
â (informative) issuer/RP semantics
â Including reliance and governance considerations
â (informative) verification procedure that an RP would follow, including subject authentication
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 wallets to issue these credentials into, based on technical and/or business criteria
â Each wallet-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 DID 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:
â Use case and summary of supported use cases
â A schema for a VC issued upon completion of an identity verification business process
â An informative description of how a relying party would verify integrity and authenticity of the VC.
â Security analysis of the supported schema
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
There is currently no work that will be identical to what this TC is trying to develop.
(2)(b) First TC Meeting
The first TC meeting will be held April 12, 2023, at 6 PM Eastern time.
(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
Kim Hamilton, Individual Contributor
Juan Caballero, Individual Contributor
Hiroshi Takashi (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 (BarbirA@cvshealth.com), as OASIS primary representative for Aetna/CVS, confirm our support for the LVCSP TC and our participants listed above.
I, Ori Eisen (o@trusona.com), 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 LVCSP TC and our participants to this TC.
(2)(f) TC Convener
Abbie Barbir, Aetna/CVS (abarbir@live.ca) will serve as convener
(2)(g) Anticipated Contributions
(2)(i) FAQ Document
(2)(j) Work Product Titles and Acronyms
|