diff --git a/packages/docs/blog/2022-04-13-crossfunctionality.md b/packages/docs/blog/2022-04-13-crossfunctionality.md index 1bb106f3..ed483648 100644 --- a/packages/docs/blog/2022-04-13-crossfunctionality.md +++ b/packages/docs/blog/2022-04-13-crossfunctionality.md @@ -4,7 +4,7 @@ description: A business developer's guide to Semantics, and an engineer's guide slug: crossfunctionationality authors: - name: Juan Caballero - title: Standards Coordinator, Centre.io (Verite) + title: Standards Coordinator, Verite url: https://github.com/bumblefudge image_url: https://avatars.githubusercontent.com/u/37127325?v=4 tags: [updates] diff --git a/packages/docs/blog/2022-05-09-how_to_create_a_verification_registry_solidity.md b/packages/docs/blog/2022-05-09-how_to_create_a_verification_registry_solidity.md index b546bf5f..b9d3f5f4 100644 --- a/packages/docs/blog/2022-05-09-how_to_create_a_verification_registry_solidity.md +++ b/packages/docs/blog/2022-05-09-how_to_create_a_verification_registry_solidity.md @@ -60,7 +60,7 @@ import "@openzeppelin/contracts/utils/cryptography/draft-EIP712.sol"; ### Verite Library -There's one additional library we want to import. This one is an interface library that allows us to more easily map the types necessary in our contract variables and functions. For brevity, we're not going to write the interface itself. We'll just copy it from the existing example from Centre. You can [grab a copy of the interface library contract here](https://github.com/centrehq/verite/blob/main/packages/contract/contracts/IVerificationRegistry.sol). +There's one additional library we want to import. This one is an interface library that allows us to more easily map the types necessary in our contract variables and functions. For brevity, we're not going to write the interface itself. We'll just copy it from the existing example from Circle. You can [grab a copy of the interface library contract here](https://github.com/centrehq/verite/blob/main/packages/contract/contracts/IVerificationRegistry.sol). Create a new contract file in your `contracts` folder and call it `IVerificationRegistry.sol`. Paste the contents of the example file linked above into that contract, then return to your `VerificationRegistry.sol` file. diff --git a/packages/docs/blog/2022-07-27-verification_patterns_2.md b/packages/docs/blog/2022-07-27-verification_patterns_2.md index 7891927c..fa0d4476 100644 --- a/packages/docs/blog/2022-07-27-verification_patterns_2.md +++ b/packages/docs/blog/2022-07-27-verification_patterns_2.md @@ -94,4 +94,4 @@ You could say that the crypto wallet delegates the encapsulation and signature o Circle’s implementation of the Verite protocol allows us to serve our customers and the dApps they interact with equally, putting the rigor of our KYC processes at the service of a process that is auditable and verifiable end-to-end without duplicating KYC process or PII from those processes across the chain of asset custody. We are proud to be driving the Verite process, and welcome more implementations, whether end-to-end issuer+verifier solutions like ours or more focused implementations that bring more wallets and more users into the ecosystem. -As the Centre team updates its documentation and sample implementation to reflect the new patterns and flows, we will continue to work with them to share the insights we are gaining from our exploratory work with dApps and clients. +As the Circle team updates its documentation and sample implementation to reflect the new patterns and flows, we will continue to work with them to share the insights we are gaining from our exploratory work with dApps and clients. diff --git a/packages/docs/blog/2023-03-06-year_in_review.md b/packages/docs/blog/2023-03-06-year_in_review.md index a2fe9f84..e32b42fb 100644 --- a/packages/docs/blog/2023-03-06-year_in_review.md +++ b/packages/docs/blog/2023-03-06-year_in_review.md @@ -4,7 +4,7 @@ description: A Year in Review slug: year-in-review-2023 authors: - name: Juan Caballero - title: Standards Coordinator, Centre.io (Verite) + title: Standards Coordinator, Verite url: https://github.com/bumblefudge image_url: https://avatars.githubusercontent.com/u/37127325?v=4 tags: [governance, research, roadmap] @@ -38,7 +38,7 @@ The role of governance in the system shifted substantially over the past year. W In particular, we worried that on-chain communication would be the hardest to align on given the business model pressures of this new 4-actor model. While "schema design", as we had been calling it, sounded like a relatively simple technical question of data modeling, it turned out to be a far more complex beast across different chains of reliance and architectural variants. -For this reason, less schema design happened in Centre-hosted working groups than we had expected. As end-to-end products continue to evolve, this kind of alignment could perhaps be premature, and many Verite partners have opted to defer this kind of harmonization until after there is significant adoption and traction. The schemas published so far are adequate to geographically-limited launches of the initial use-case, and as the sphere of supported geographies and use-cases expands, or as more players enter the space and demand grows for federation and interoperability, we look forward to truly viable self-governance. In the meantime, we will continue technical research and design work that falls into four categories: +For this reason, less schema design happened in Circle-hosted working groups than we had expected. As end-to-end products continue to evolve, this kind of alignment could perhaps be premature, and many Verite partners have opted to defer this kind of harmonization until after there is significant adoption and traction. The schemas published so far are adequate to geographically-limited launches of the initial use-case, and as the sphere of supported geographies and use-cases expands, or as more players enter the space and demand grows for federation and interoperability, we look forward to truly viable self-governance. In the meantime, we will continue technical research and design work that falls into four categories: 1. On-chain Design 2. Architectural Design & Adoption diff --git a/packages/docs/verite/appendix/primer.md b/packages/docs/verite/appendix/primer.md index d4dcf58f..9fddb0ea 100644 --- a/packages/docs/verite/appendix/primer.md +++ b/packages/docs/verite/appendix/primer.md @@ -89,7 +89,7 @@ Verite's demo wallet generates and manages DIDs and associated key pairs on beha In a typical decentralized identity case, a verifier would request a Verifiable Credential from an identity holder. That requires discovery or knowledge of the holder first _(simple analogy: someone asks you to prove you are vaccinated)_. -But Centre’s use cases can also involve no knowledge of a holder endpoint at first, in which verifiers query the peer network to find one or more DIDs that can satisfy the claim in the query using a particular Verifiable Credential _(simple analogy: someone posts a notice in a public place asking to be privately and anonymously messaged by anyone who chooses to prove they are vaccinated)_. +But Circle's use cases can also involve no knowledge of a holder endpoint at first, in which verifiers query the peer network to find one or more DIDs that can satisfy the claim in the query using a particular Verifiable Credential _(simple analogy: someone posts a notice in a public place asking to be privately and anonymously messaged by anyone who chooses to prove they are vaccinated)_. **VC Structure** diff --git a/packages/docs/verite/developers/tutorials/creating-a-registry-contract-in-solidity.md b/packages/docs/verite/developers/tutorials/creating-a-registry-contract-in-solidity.md index c537a415..392e2645 100644 --- a/packages/docs/verite/developers/tutorials/creating-a-registry-contract-in-solidity.md +++ b/packages/docs/verite/developers/tutorials/creating-a-registry-contract-in-solidity.md @@ -43,7 +43,7 @@ import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol"; import "@openzeppelin/contracts/utils/cryptography/draft-EIP712.sol"; ``` -There's one additional library we want to import. This one is an interface library that allows us to more easily map the types necessary in our contract variables and functions. For brevity, we're not going to write the interface itself. We'll just copy it from the existing example from Centre. You can [grab a copy of the interface library contract here](https://github.com/centrehq/verite/blob/main/packages/contract/contracts/IVerificationRegistry.sol). +There's one additional library we want to import. This one is an interface library that allows us to more easily map the types necessary in our contract variables and functions. For brevity, we're not going to write the interface itself. We'll just copy it from the existing example from Circle. You can [grab a copy of the interface library contract here](https://github.com/centrehq/verite/blob/main/packages/contract/contracts/IVerificationRegistry.sol). Create a new contract file in your `contracts` folder and call it `IVerificationRegistry.sol`. Paste the contents of the example file linked above into that contract, then return to your `VerificationRegistry.sol` file. diff --git a/packages/docs/verite/issuers/getting-started.md b/packages/docs/verite/issuers/getting-started.md index 07022a7f..a513377f 100644 --- a/packages/docs/verite/issuers/getting-started.md +++ b/packages/docs/verite/issuers/getting-started.md @@ -112,10 +112,6 @@ Take a minute to ask yourself some difficult strategic questions: your support to wallets with built-in per-transaction or per-session biometrics, etc. -Over time, we will be updating and detailing this guidance, but in the meantime, -feel free to reach out to [the Verite team at -Centre.io](mailto:verite@centre.io) for guidance on where to start and which -wallets are already supporting these interfaces. ## Architectural options @@ -147,7 +143,4 @@ Once you have clear your use-cases and your high-level architecture, you arrive at the build-or-buy decision. If you want to issue the credentials you will be responsible for yourself, there are tutorials and documents to guide you through the process in the ["For Developers" section of this -site](https://verite.id/verite/developers/getting-started). If you are curious -about credential Issuance-as-a-Service, reach out to [the Verite team at -Centre.io](mailto:verite@centre.io) and we can refer you to colleagues in the -space operating on this kind of model. +site](https://verite.id/verite/developers/getting-started). diff --git a/packages/docs/verite/issuers/issuer-registry-pvg.md b/packages/docs/verite/issuers/issuer-registry-pvg.md index f10d15c6..f719491a 100644 --- a/packages/docs/verite/issuers/issuer-registry-pvg.md +++ b/packages/docs/verite/issuers/issuer-registry-pvg.md @@ -8,7 +8,7 @@ The issuer registry pre-viable governance (PVG) is a simple demonstration issuer ## Usage/Intent of the PVG Verite Issuer Registry -The PVG Verite Issuer Registry focuses exclusively on Issuer ID and authorization and leaves out of scope governance considerations. As such, this should be viewed as an experimental implementation for the initial Verite issuers as the governance structure is being developed, with only manual and Centre-governed additions and removals until such a time as Verite issuance can be communally self-governing. +The PVG Verite Issuer Registry focuses exclusively on Issuer ID and authorization and leaves out of scope governance considerations. As such, this should be viewed as an experimental implementation for the initial Verite issuers as the governance structure is being developed, with only manual and Circle-governed additions and removals until such a time as Verite issuance can be communally self-governing. The PVG Verite Issuer Registry identifies entities authorized to issue Verite credentials (segmented by different credential definitions); for each, it provides the exact issuer-service identifier (usually a DID) included in their Verite credentials, along with associated metadata. @@ -39,7 +39,7 @@ All is to be interpreted as experimental for PVG and subject to revision. The following roles are referred to below - Verite owners/administrators: - - Initially Verite github repo (centrehq) administrators. + - Initially Verite github repo administrators. - Sole technical/logistic ability to approval and merge PRs - Later to be replaced with real governance/membership scheme - Verite participants: @@ -56,6 +56,6 @@ The following roles are referred to below - Organization must sign Verite CLA - No substantive objections from WG members, as determined by WG chair - Process for updates to issuer registry: - - Any individual by any organization covered by Verite CLA may open PR against Centre Verite github org + - Any individual by any organization covered by Verite CLA may open PR against the Verite github org - Verite repo owners/administrators must review, approve, and merge - Github signed commits are required (they are enabled repo-wide on Verite github repo) diff --git a/packages/docs/verite/overview/design-overview.md b/packages/docs/verite/overview/design-overview.md index d2f8b9f9..e417f70c 100644 --- a/packages/docs/verite/overview/design-overview.md +++ b/packages/docs/verite/overview/design-overview.md @@ -15,7 +15,7 @@ Verite's decentralized identity standards aim to satisfy the following design pr - **Cryptographically verifiable:** Based on cryptographic proofs rather than out-of-band trust. -- **Resolvable and interoperable:** Open to any solution that recognizes the common protocols and data model and requires no one specific software vendor implementation, including any that Centre or its members may create. +- **Resolvable and interoperable:** Open to any solution that recognizes the common protocols and data model and requires no one specific software vendor implementation, including any that Circle or its members may create. - **Transparent:** Identity holders know when and how their identity data is being requested and used. @@ -27,7 +27,7 @@ Interoperability across the ecosystem is an over-arching Verite goal. There has Verite's specific tactical goals are to: (a) define data models (schemas) that should be shared and exist as common building blocks for all parties as a public good; and (b) define the protocols for requesting and delivering identity claims in a manner that supports crypto finance use cases. -The intent is to enable any member of the broader crypto ecosystem to develop products and solutions that are inherently compliant and interoperable with each other, and to do so in a manner that is open, transparent, and usable by anyone, whether connected to the Centre Consortium and the USDC ecosystem or not. +The intent is to enable any member of the broader crypto ecosystem to develop products and solutions that are inherently compliant and interoperable with each other, and to do so in a manner that is open, transparent, and usable by anyone, whether connected to Circle and the USDC ecosystem or not. A process goal is to maintain transparency and openness in the iteration of the protocols and data models. Anyone is free to use the source code, modify it, and submit improvements to it. diff --git a/packages/docs/verite/overview/governance-overview.md b/packages/docs/verite/overview/governance-overview.md index 1a95dced..efdc2ac9 100644 --- a/packages/docs/verite/overview/governance-overview.md +++ b/packages/docs/verite/overview/governance-overview.md @@ -17,7 +17,7 @@ In a network with multiple issuers, every VC issued should be on equal footing. ## Current State: Boot-strapping an Ecosystem -Verite is currently orchestrated by Centre in close collaboration with its initial implementers, and grounded in feedback from early evaluators who commit seriously to considering our work to date. This is “strategically centralized,” in the sense that Centre is currently the hub at the center of major technical and business planning with implementers, but the multi-lateral collaboration has already started in Working Groups, bound by multi-lateral IP/NDA agreements. One such working group is actually focused on roadmapping and elaborating everything that follows; to get involved, reach out to Centre. +Verite is currently orchestrated by Circle in close collaboration with its initial implementers, and grounded in feedback from early evaluators who commit seriously to considering our work to date. This is “strategically centralized,” in the sense that Circle is currently the hub at the center of major technical and business planning with implementers, but the multi-lateral collaboration has already started in Working Groups, bound by multi-lateral IP/NDA agreements. One such working group is actually focused on roadmapping and elaborating everything that follows; to get involved, reach out to Circle. ## Target-State: Three Interlocking Governance Mechanisms @@ -56,11 +56,11 @@ The governance framework will define (not exhaustive): The “**Network Utilities**” that power Verite provide common services to all participants and end-users in the Verite ecosystem. -The first and most structural network utility is the **Trusted Identity Registry**. The Trusted Identity Registry defines which Issuers and Verifiers can be trusted to adhere to Centre Verite Standards. It functions as an “key directory” providing authoritative key material to prevent phishing or impersonation within the system. As Verite scales up, it will also include up-to-date information on conformance testing, to facilitate real-time decision making about the trustworthiness and roadworthiness of each actor’s implementation and credentials. Centre reserves the right to remove actors from the Registry if they have not signed the Rulebook or have been judged by the community not to be honoring it. +The first and most structural network utility is the **Trusted Identity Registry**. The Trusted Identity Registry defines which Issuers and Verifiers can be trusted to adhere to Circle Verite Standards. It functions as an “key directory” providing authoritative key material to prevent phishing or impersonation within the system. As Verite scales up, it will also include up-to-date information on conformance testing, to facilitate real-time decision making about the trustworthiness and roadworthiness of each actor’s implementation and credentials. Circle reserves the right to remove actors from the Registry if they have not signed the Rulebook or have been judged by the community not to be honoring it. #### Detailed Remit: Trusted Identity Registry -Centre will build, maintain, and publish the Trusted Identity Registry that includes Issuers and Verifiers which have applied for and been approved by the Verite Governance Board to join the registry. +Circle will build, maintain, and publish the Trusted Identity Registry that includes Issuers and Verifiers which have applied for and been approved by the Verite Governance Board to join the registry. Entities in the registry adhere to technical, operational, legal, regulatory, and compliance standards defined by Verite Governance Board. Verifiers and Issuers in the registry must sign a Verite Rulebook which defines the rights, obligations, standards, reps & warranties, etc that they must adhere to. The rulebook dictates the conditions under which a VC can be issued, verified, and or/revoked @@ -91,6 +91,3 @@ The Verite Rulebook will cover a number of different topics, including but not l * Financial requirements of the issuers/verifiers * SLAs for the network utilities (e.g. uptime, resiliency, latency, etc) -## Roadmap - -We are in the early stages of defining the "minimum viable governance" with key stakeholders as we establish the ecosystem. If you’re interested in participating, please contact us at verite@centre.io \ No newline at end of file diff --git a/packages/docs/verite/patterns/travel-rule.md b/packages/docs/verite/patterns/travel-rule.md index 4e8c6f60..7e09dda7 100644 --- a/packages/docs/verite/patterns/travel-rule.md +++ b/packages/docs/verite/patterns/travel-rule.md @@ -6,7 +6,7 @@ sidebar_position: 7 The Verite open source repo includes some code that provides a cursory demonstration of how exchanging verifiable credentials could be a core component of scalable and open ecosystems for financial institutions to comply with Travel Rule reporting obligations with minimal privacy, data leakage, and security risks. -In addition to this high-level "proof of concept," long-tail research in ongoing into FATF use cases forming a cornerstone of Verite in the latter part of 2023. To get involved with the research team, contact Verite's [Standards team at Centre.io](mailto:verite@centre.io). +In addition to this high-level "proof of concept," long-tail research in ongoing into FATF use cases forming a cornerstone of Verite in the latter part of 2023. Please note: TRUST, TRISA, and other protocols that currently do not use Verifiable Credentials as an exchange format for FATF counterparty reporting are in no way incompatible with this group's approach; our goal is to focus on the privacy risks and protocols for mutual discovery and interactions, which can bootstrap any protocol between financial institutions once validated. diff --git a/packages/docs/verite/verifiers/getting-started.md b/packages/docs/verite/verifiers/getting-started.md index f052d0ff..c6665e17 100644 --- a/packages/docs/verite/verifiers/getting-started.md +++ b/packages/docs/verite/verifiers/getting-started.md @@ -58,7 +58,6 @@ Take a minute to ask yourself some difficult strategic questions: - Retail wallets tend to have long, slow upgrade cycles and governance processes. Conversely, many companies contract out to wallet firms to provide highly-customized "provisioned wallets" to their employees for managing company funds. As Verite capabilities are standardized and rolled out as common APIs, these may be a better match for "testing the waters" - Depending on which exact credentials you issue and your risk tolerance, you might have different requirements for identity-assurance, sybil-resistance/uniqueness, deduplication, or liveness/biometric binding. I.e., if your use-case requires you to be certain that the authorized employee is authorizing each transaction of a company wallet, you may want to limit your support to wallets with built-in per-transaction or per-session biometrics, etc. -Over time, we will be updating and detailing this guidance, but in the meantime, feel free to reach out to [the Verite team at Centre.op](mailto:verite@centre.io) for guidance on where to start and which wallets are already supporting these interfaces. ## Architectural options @@ -77,6 +76,6 @@ for implementation guidance and code examples, and and [wallet-bound issuance service setup](https://verite.id/verite/developers/issuer-setup) for reference. -Once you have clear your use-cases and your high-level architecture, you arrive at the build-or-buy decision. Verifying Verite credentials at scale and in production can be a massive undertaking if you're not familiar with OIDC token, authorization issues, applied cryptography, or other related problems in web engineering. That said, they are just signed JSON! If you're considering building a verifier for your environment, start with the tutorials and documents that guide you through the process in the ["For Developers" section of this site](https://verite.id/verite/developers/getting-started). If you have any questions, just reach out to [the Verite team at Centre.io](mailto:verite@centre.io). +Once you have clear your use-cases and your high-level architecture, you arrive at the build-or-buy decision. Verifying Verite credentials at scale and in production can be a massive undertaking if you're not familiar with OIDC token, authorization issues, applied cryptography, or other related problems in web engineering. That said, they are just signed JSON! If you're considering building a verifier for your environment, start with the tutorials and documents that guide you through the process in the ["For Developers" section of this site](https://verite.id/verite/developers/getting-started). -If outsourcing this layer is more appealing, there are already a number of verifiers that offer the verification and validation/initial-processing of Verite credentials as a service, which can deliver definitive answers about which wallets/address to sort into which buckets or trust-levels over APIs, oracles, and/or on-chain registries. Some of these are even free to use in production, at scale! If you are curious about credential Verification-as-a-Service, reach out to [the Verite team at Centre.io](mailto:verite@centre.io) and we can refer you to Verite adopters releasing these products already. +If outsourcing this layer is more appealing, there are already a number of verifiers that offer the verification and validation/initial-processing of Verite credentials as a service, which can deliver definitive answers about which wallets/address to sort into which buckets or trust-levels over APIs, oracles, and/or on-chain registries. Some of these are even free to use in production, at scale! diff --git a/packages/docs/verite/wallets/getting-started.md b/packages/docs/verite/wallets/getting-started.md index 8616808b..aa75f25e 100644 --- a/packages/docs/verite/wallets/getting-started.md +++ b/packages/docs/verite/wallets/getting-started.md @@ -49,7 +49,7 @@ Verite's handling of verifiable credentials is best understood as a User-Experie ### Storage of Verifiable Credentials -The Verite standards strive to remain maximally unopinionated and flexible about storage, as wallets today hardly have a standardized way of handling file storage in-wallet or in vaults. We have prototyped both a "split wallet" design, where verifiable credentials and user consent to shared are handled by an entirely separate piece of software (i.e., a device-specific browser-extension for conveying identity data) and a "minimum viable hybrid wallet", a cryptocurrency wallet which only handles Verite credentials in their simplest form in instance/device-specific local storage. Storage-supplemental dapps and PWAs are also under prototyping efforts in parallel, to allow an unmodified, traditional Wallet-Connect wallet to spin up a cross-device "vault" for verifiable credentials, with delegated signing rights over its contents for cleaner audit trails. We look forward to publishing the results of this research as replicable and even standardizable primitives soon.in the meantime, feel free to reach out to [the Verite team at Centre.op](mailto:verite@centre.io) +The Verite standards strive to remain maximally unopinionated and flexible about storage, as wallets today hardly have a standardized way of handling file storage in-wallet or in vaults. We have prototyped both a "split wallet" design, where verifiable credentials and user consent to shared are handled by an entirely separate piece of software (i.e., a device-specific browser-extension for conveying identity data) and a "minimum viable hybrid wallet", a cryptocurrency wallet which only handles Verite credentials in their simplest form in instance/device-specific local storage. Storage-supplemental dapps and PWAs are also under prototyping efforts in parallel, to allow an unmodified, traditional Wallet-Connect wallet to spin up a cross-device "vault" for verifiable credentials, with delegated signing rights over its contents for cleaner audit trails. We look forward to publishing the results of this research as replicable and even standardizable primitives soon. ### Key Custody