From 11befb2f4a276215c74a7130b01318456465d9c4 Mon Sep 17 00:00:00 2001 From: Jess Heron Date: Wed, 11 Oct 2023 16:40:18 -0700 Subject: [PATCH 1/4] Strike plain language uses of 'Centre'. --- packages/docs/blog/2022-04-13-crossfunctionality.md | 2 +- ...-09-how_to_create_a_verification_registry_solidity.md | 2 +- packages/docs/blog/2022-07-27-verification_patterns_2.md | 2 +- packages/docs/blog/2023-03-06-year_in_review.md | 4 ++-- packages/docs/verite/appendix/primer.md | 2 +- .../creating-a-registry-contract-in-solidity.md | 2 +- packages/docs/verite/issuers/getting-started.md | 9 +-------- packages/docs/verite/issuers/issuer-registry-pvg.md | 6 +++--- packages/docs/verite/overview/design-overview.md | 4 ++-- packages/docs/verite/overview/governance-overview.md | 9 +++------ packages/docs/verite/patterns/travel-rule.md | 2 +- packages/docs/verite/verifiers/getting-started.md | 5 ++--- packages/docs/verite/wallets/getting-started.md | 2 +- 13 files changed, 20 insertions(+), 31 deletions(-) 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 From 9cd464f2f3851afe41c7d63450a8ec5b104c05ac Mon Sep 17 00:00:00 2001 From: Jess Heron Date: Thu, 12 Oct 2023 14:28:37 -0700 Subject: [PATCH 2/4] Updates copyright details from Centre to Circle. --- LICENSE | 2 +- packages/contract/LICENSE | 2 +- packages/contract/contracts/IVerificationRegistry.sol | 2 +- packages/contract/contracts/PermissionedToken.sol | 2 +- packages/contract/contracts/ThresholdToken.sol | 2 +- packages/contract/contracts/VerificationRegistry.sol | 3 ++- packages/demo-issuer/LICENSE | 2 +- packages/demo-revocation/LICENSE | 2 +- packages/demo-verifier/LICENSE | 2 +- packages/docs/docusaurus.config.js | 2 +- packages/e2e-demo/LICENSE | 2 +- packages/verite/LICENSE | 2 +- 12 files changed, 13 insertions(+), 12 deletions(-) diff --git a/LICENSE b/LICENSE index 3e2d1ab4..aaae7530 100644 --- a/LICENSE +++ b/LICENSE @@ -1,4 +1,4 @@ -Copyright (c) 2022 CENTRE CONSORTIUM, LLC +Copyright (c) 2023 Circle Internet Financial Limited Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal diff --git a/packages/contract/LICENSE b/packages/contract/LICENSE index 99091d4a..aaae7530 100644 --- a/packages/contract/LICENSE +++ b/packages/contract/LICENSE @@ -1,4 +1,4 @@ -Copyright (c) 2022 CENTRE SECZ +Copyright (c) 2023 Circle Internet Financial Limited Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal diff --git a/packages/contract/contracts/IVerificationRegistry.sol b/packages/contract/contracts/IVerificationRegistry.sol index 335ebbfe..277b60b3 100644 --- a/packages/contract/contracts/IVerificationRegistry.sol +++ b/packages/contract/contracts/IVerificationRegistry.sol @@ -1,7 +1,7 @@ /** * SPDX-License-Identifier: MIT * - * Copyright (c) 2018-2022 CENTRE SECZ + * Copyright (c) 2023 Circle Internet Financial Limited * * Permission is hereby granted, free of charge, to any person obtaining a copy * of this software and associated documentation files (the "Software"), to deal diff --git a/packages/contract/contracts/PermissionedToken.sol b/packages/contract/contracts/PermissionedToken.sol index 5df881c3..4057f6a3 100644 --- a/packages/contract/contracts/PermissionedToken.sol +++ b/packages/contract/contracts/PermissionedToken.sol @@ -1,7 +1,7 @@ /** * SPDX-License-Identifier: MIT * - * Copyright (c) 2018-2022 CENTRE SECZ + * Copyright (c) 2023 Circle Internet Financial Limited * * Permission is hereby granted, free of charge, to any person obtaining a copy * of this software and associated documentation files (the "Software"), to deal diff --git a/packages/contract/contracts/ThresholdToken.sol b/packages/contract/contracts/ThresholdToken.sol index d60da0c7..148859e0 100644 --- a/packages/contract/contracts/ThresholdToken.sol +++ b/packages/contract/contracts/ThresholdToken.sol @@ -1,7 +1,7 @@ /** * SPDX-License-Identifier: MIT * - * Copyright (c) 2018-2022 CENTRE SECZ + * Copyright (c) 2023 Circle Internet Financial Limited * * Permission is hereby granted, free of charge, to any person obtaining a copy * of this software and associated documentation files (the "Software"), to deal diff --git a/packages/contract/contracts/VerificationRegistry.sol b/packages/contract/contracts/VerificationRegistry.sol index cdcd5d85..52156e73 100644 --- a/packages/contract/contracts/VerificationRegistry.sol +++ b/packages/contract/contracts/VerificationRegistry.sol @@ -1,7 +1,8 @@ /** * SPDX-License-Identifier: MIT * - * Copyright (c) 2018-2022 CENTRE SECZ + * Copyright (c) 2023 Circle Internet Financial Limited + * * Permission is hereby granted, free of charge, to any person obtaining a copy * of this software and associated documentation files (the "Software"), to deal diff --git a/packages/demo-issuer/LICENSE b/packages/demo-issuer/LICENSE index 99091d4a..aaae7530 100644 --- a/packages/demo-issuer/LICENSE +++ b/packages/demo-issuer/LICENSE @@ -1,4 +1,4 @@ -Copyright (c) 2022 CENTRE SECZ +Copyright (c) 2023 Circle Internet Financial Limited Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal diff --git a/packages/demo-revocation/LICENSE b/packages/demo-revocation/LICENSE index 99091d4a..aaae7530 100644 --- a/packages/demo-revocation/LICENSE +++ b/packages/demo-revocation/LICENSE @@ -1,4 +1,4 @@ -Copyright (c) 2022 CENTRE SECZ +Copyright (c) 2023 Circle Internet Financial Limited Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal diff --git a/packages/demo-verifier/LICENSE b/packages/demo-verifier/LICENSE index 99091d4a..aaae7530 100644 --- a/packages/demo-verifier/LICENSE +++ b/packages/demo-verifier/LICENSE @@ -1,4 +1,4 @@ -Copyright (c) 2022 CENTRE SECZ +Copyright (c) 2023 Circle Internet Financial Limited Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal diff --git a/packages/docs/docusaurus.config.js b/packages/docs/docusaurus.config.js index 3ef0e233..c9e4388e 100644 --- a/packages/docs/docusaurus.config.js +++ b/packages/docs/docusaurus.config.js @@ -61,7 +61,7 @@ module.exports = { ] } ], - copyright: `Copyright © ${new Date().getFullYear()} Centre Consortium, LLC. Built with Docusaurus.` + copyright: `Copyright © ${new Date().getFullYear()} Circle Internet Financial Limited. Built with Docusaurus.` }, prism: { theme: lightCodeTheme, diff --git a/packages/e2e-demo/LICENSE b/packages/e2e-demo/LICENSE index 99091d4a..aaae7530 100644 --- a/packages/e2e-demo/LICENSE +++ b/packages/e2e-demo/LICENSE @@ -1,4 +1,4 @@ -Copyright (c) 2022 CENTRE SECZ +Copyright (c) 2023 Circle Internet Financial Limited Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal diff --git a/packages/verite/LICENSE b/packages/verite/LICENSE index 99091d4a..aaae7530 100644 --- a/packages/verite/LICENSE +++ b/packages/verite/LICENSE @@ -1,4 +1,4 @@ -Copyright (c) 2022 CENTRE SECZ +Copyright (c) 2023 Circle Internet Financial Limited Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal From 5f3965d7279a4d56e9caa7946c42d8277c27b3c8 Mon Sep 17 00:00:00 2001 From: Jess Heron Date: Thu, 12 Oct 2023 14:31:50 -0700 Subject: [PATCH 3/4] Updates language to remove Centre for Circle; removes Centre-related schema. --- README.md | 2 +- packages/contract/README.md | 2 +- packages/contract/hardhat.config.ts | 2 +- packages/contract/scripts/deploy.ts | 8 ++++---- packages/contract/test/VerificationRegistryTests.ts | 12 ++++++------ packages/demo-issuer/README.md | 2 +- packages/demo-revocation/README.md | 2 +- packages/demo-verifier/README.md | 2 +- packages/docs/blog/2022-03-30-introducing_verite.md | 4 ++-- packages/docs/docusaurus.config.js | 4 ++-- packages/docs/verite/appendix/primer.md | 3 +-- .../developers/tutorials/solidity-verifications.md | 10 +++++----- packages/docs/verite/developers/wallet-guide.md | 5 +---- packages/e2e-demo/README.md | 4 ++-- packages/e2e-demo/components/shared/Layout.tsx | 2 +- packages/e2e-demo/pages/demos/issuer/kyc.tsx | 2 +- packages/solana/programs/verity/src/lib.rs | 2 +- packages/solana/tests/verity.ts | 2 +- packages/verite/README.md | 2 +- packages/verite/lib/verifier/result.ts | 4 ++-- .../lib/verifier/presentation-definitions.test.ts | 6 +++--- packages/verite/test/lib/verifier/result.test.ts | 6 +++--- .../test/lib/verifier/verification-offer.test.ts | 4 ++-- packages/wallet/README.md | 2 +- packages/wallet/app.json | 2 +- 25 files changed, 46 insertions(+), 50 deletions(-) diff --git a/README.md b/README.md index d84f7950..fcc58211 100644 --- a/README.md +++ b/README.md @@ -163,7 +163,7 @@ Occasionally, the local hardhat ethereum node and MetaMask become out of sync. I ## Contributors -- [Kim Hamilton Duffy](https://github.com/kimdhamilton) ([Centre Consortium](https://centre.io)) +- [Kim Hamilton Duffy](https://github.com/kimdhamilton) - [Sean Neville](https://github.com/psnevio) ([Xdotzero](http://xdotzero.com)) - [Brice Stacey](https://github.com/bricestacey) ([M2 Labs](https://m2.xyz)) - [Matt Venables](https://github.com/venables) ([M2 Labs](https://m2.xyz)) diff --git a/packages/contract/README.md b/packages/contract/README.md index f08ee2da..89e29ace 100644 --- a/packages/contract/README.md +++ b/packages/contract/README.md @@ -132,7 +132,7 @@ Since the full, fixed supply is issued to the contract creator, we used that sam ## Contributors -- [Kim Hamilton Duffy](https://github.com/kimdhamilton) ([Centre Consortium](https://centre.io)) +- [Kim Hamilton Duffy](https://github.com/kimdhamilton) - [Sean Neville](https://github.com/psnevio) ([Xdotzero](http://xdotzero.com)) - [Brice Stacey](https://github.com/bricestacey) ([M2 Labs](https://m2.xyz)) - [Matt Venables](https://github.com/venables) ([M2 Labs](https://m2.xyz)) diff --git a/packages/contract/hardhat.config.ts b/packages/contract/hardhat.config.ts index c1a67187..03b785e0 100644 --- a/packages/contract/hardhat.config.ts +++ b/packages/contract/hardhat.config.ts @@ -256,7 +256,7 @@ task( } const verificationResult = { - schema: "centre.io/credentials/kyc", + schema: "", subject: taskArgs.address, expiration: Math.floor(Date.now() / 1000) + 60 // 1 minute } diff --git a/packages/contract/scripts/deploy.ts b/packages/contract/scripts/deploy.ts index 087d8f63..7e8c7137 100644 --- a/packages/contract/scripts/deploy.ts +++ b/packages/contract/scripts/deploy.ts @@ -118,7 +118,7 @@ async function registerVerifications(registry: Contract, addresses: string[]) { for (const address of addresses) { const verificationResult = { - schema: "centre.io/credentials/kyc", + schema: "", subject: address, expiration: expiration } @@ -151,9 +151,9 @@ async function createTrustedVerifier( ) { for (const address of verifiers) { const testVerifierInfo = { - name: hre.ethers.utils.formatBytes32String("Centre Consortium"), - did: "did:web:centre.io", - url: "https://centre.io/about", + name: hre.ethers.utils.formatBytes32String("Circle Internet Financial"), + did: "did:web:circle.com", + url: "https://www.circle.com/en/about-circle", signer: address } diff --git a/packages/contract/test/VerificationRegistryTests.ts b/packages/contract/test/VerificationRegistryTests.ts index a05b7712..5553dce9 100644 --- a/packages/contract/test/VerificationRegistryTests.ts +++ b/packages/contract/test/VerificationRegistryTests.ts @@ -33,9 +33,9 @@ describe("VerificationRegistry", function () { // create a test verifier const testVerifierInfo = { - name: ethers.utils.formatBytes32String("Centre Consortium"), - did: "did:web:centre.io", - url: "https://centre.io/about", + name: ethers.utils.formatBytes32String("Circle Internet Financial"), + did: "did:web:circle.com", + url: "https://www.circle.com/en/about-circle", signer: signer.address } @@ -71,7 +71,7 @@ describe("VerificationRegistry", function () { }) it("Should update an existing verifier", async function () { - testVerifierInfo.url = "https://centre.io" + testVerifierInfo.url = "https://circle.com" const setVerifierTx = await verificationRegistry.updateVerifier( contractOwnerAddress, testVerifierInfo @@ -137,7 +137,7 @@ describe("VerificationRegistry", function () { ] } verificationResult = { - schema: "centre.io/credentials/kyc", + schema: "", subject: subjectAddress, expiration: expiration } @@ -239,7 +239,7 @@ describe("VerificationRegistry", function () { // register owner as verified it("Should register token owner as verified", async function () { verificationResult = { - schema: "centre.io/credentials/kyc", + schema: "", subject: tokenOwner, expiration: expiration } diff --git a/packages/demo-issuer/README.md b/packages/demo-issuer/README.md index eb81e6dd..a3b50fd2 100644 --- a/packages/demo-issuer/README.md +++ b/packages/demo-issuer/README.md @@ -60,7 +60,7 @@ Note that this is contingent on metamask actually supporting Verite. ## Contributors -- [Kim Hamilton Duffy](https://github.com/kimdhamilton) ([Centre Consortium](https://centre.io)) +- [Kim Hamilton Duffy](https://github.com/kimdhamilton) - [Sean Neville](https://github.com/psnevio) ([Xdotzero](http://xdotzero.com)) - [Brice Stacey](https://github.com/bricestacey) ([M2 Labs](https://m2.xyz)) - [Matt Venables](https://github.com/venables) ([M2 Labs](https://m2.xyz)) diff --git a/packages/demo-revocation/README.md b/packages/demo-revocation/README.md index 04c0fee3..bce735ee 100644 --- a/packages/demo-revocation/README.md +++ b/packages/demo-revocation/README.md @@ -45,7 +45,7 @@ You can read more about the Next.js folder structure in [their documentation](ht ## Contributors -- [Kim Hamilton Duffy](https://github.com/kimdhamilton) ([Centre Consortium](https://centre.io)) +- [Kim Hamilton Duffy](https://github.com/kimdhamilton) - [Sean Neville](https://github.com/psnevio) ([Xdotzero](http://xdotzero.com)) - [Brice Stacey](https://github.com/bricestacey) ([M2 Labs](https://m2.xyz)) - [Matt Venables](https://github.com/venables) ([M2 Labs](https://m2.xyz)) diff --git a/packages/demo-verifier/README.md b/packages/demo-verifier/README.md index 07378248..a4384fd8 100644 --- a/packages/demo-verifier/README.md +++ b/packages/demo-verifier/README.md @@ -60,7 +60,7 @@ Issuance to metamask, or some browser-based extension wallet, is very similar. S ## Contributors -- [Kim Hamilton Duffy](https://github.com/kimdhamilton) ([Centre Consortium](https://centre.io)) +- [Kim Hamilton Duffy](https://github.com/kimdhamilton) - [Sean Neville](https://github.com/psnevio) ([Xdotzero](http://xdotzero.com)) - [Brice Stacey](https://github.com/bricestacey) ([M2 Labs](https://m2.xyz)) - [Matt Venables](https://github.com/venables) ([M2 Labs](https://m2.xyz)) diff --git a/packages/docs/blog/2022-03-30-introducing_verite.md b/packages/docs/blog/2022-03-30-introducing_verite.md index 1171a22b..342e297e 100644 --- a/packages/docs/blog/2022-03-30-introducing_verite.md +++ b/packages/docs/blog/2022-03-30-introducing_verite.md @@ -20,9 +20,9 @@ The answer is Verifiable Credentials (VCs). VCs are on a web standards track and ## What Is Verite? -Verite is a collaborative and open source initiative spearheaded by the [Centre Consortium](https://www.centre.io/). Centre's focus is to "provide the governance and standards for the future digital financial ecosystem." Verite is one output of the collaborative effort of Centre. +Verite is a collaborative and open source initiative spearheaded by the Circle, and its focus is to "provide the governance and standards for the future digital financial ecosystem." Verite is one output of the collaborative effort. -While contributions to the VCs standards themselves is important, and Centre is an active participant alongside the W3C, tools that make it easy to implement and leverage VCs are just as important. As such, Centre began work last year on Verite, an open source library designed to make managing VCs easier. +While contributions to the VCs standards themselves is important, and Circle is an active participant alongside the W3C, tools that make it easy to implement and leverage VCs are just as important. As such, Circle began work last year on Verite, an open source library designed to make managing VCs easier. Currently available in TypeScript and [published through NPM](https://www.npmjs.com/package/verite), the Verite library seeks to make it easier to implement VCs in a variety of forms. The library is early and an additional goal of the library is to collect community feedback. diff --git a/packages/docs/docusaurus.config.js b/packages/docs/docusaurus.config.js index c9e4388e..ff831e7b 100644 --- a/packages/docs/docusaurus.config.js +++ b/packages/docs/docusaurus.config.js @@ -5,12 +5,12 @@ const lightCodeTheme = require("prism-react-renderer/themes/github") module.exports = { title: "Verite Documentation", tagline: "Verite decentralized identity for DeFi", - url: "https://docs.centre.io", + url: "https://verite.id/", baseUrl: "/", onBrokenLinks: "throw", onBrokenMarkdownLinks: "warn", favicon: "img/favicon.ico", - organizationName: "centre.io", + organizationName: "circle.com", projectName: "verite-docs", themeConfig: { navbar: { diff --git a/packages/docs/verite/appendix/primer.md b/packages/docs/verite/appendix/primer.md index 9fddb0ea..83b8f33a 100644 --- a/packages/docs/verite/appendix/primer.md +++ b/packages/docs/verite/appendix/primer.md @@ -101,8 +101,7 @@ But Circle's use cases can also involve no knowledge of a holder endpoint at fir ```json { "@context": [ - "https://www.w3.org/2018/credentials/v1", - "https://centre.io/contexts/identity.jsonld" + "https://www.w3.org/2018/credentials/v1" ], "type": [ "VerifiableCredential", diff --git a/packages/docs/verite/developers/tutorials/solidity-verifications.md b/packages/docs/verite/developers/tutorials/solidity-verifications.md index 03ba2d87..51fbb6b6 100644 --- a/packages/docs/verite/developers/tutorials/solidity-verifications.md +++ b/packages/docs/verite/developers/tutorials/solidity-verifications.md @@ -149,9 +149,9 @@ Now that we've seen the contract properly reject an address that is not listed a ```js // create a test verifier const testVerifierInfo = { - name: ethers.utils.formatBytes32String("Centre Consortium"), - did: "did:web:centre.io", - url: "https://centre.io/about", + name: ethers.utils.formatBytes32String("Circle Internet Financial"), + did: "did:web:circle.com", + url: "https://www.circle.com/en/about-circle", signer: signer.address } @@ -229,7 +229,7 @@ Verifier information can change, so it's important to be able to update verifier ```js it("Should update an existing verifier", async function () { - testVerifierInfo.url = "https://centre.io" + testVerifierInfo.url = "https://circle.com" const setVerifierTx = await verificationRegistry.updateVerifier( contractOwnerAddress, testVerifierInfo @@ -305,7 +305,7 @@ it("Should format a structured verification result", async function () { ] } verificationResult = { - schema: "centre.io/credentials/kyc", + schema: "circle.com/credentials/kyc", subject: subjectAddress, expiration: expiration } diff --git a/packages/docs/verite/developers/wallet-guide.md b/packages/docs/verite/developers/wallet-guide.md index 18b412b3..f7da3d4b 100644 --- a/packages/docs/verite/developers/wallet-guide.md +++ b/packages/docs/verite/developers/wallet-guide.md @@ -5,8 +5,6 @@ sidebar_position: 9 # Verite Wallet Integration Guide -**Contact**: [verite-dev@centre.io](mailto:verite-dev@centre.io) - This guide is written for developers seeking to integrate the "wallet-bound" Verite flows and data models into custodial or non-custodial wallets. What follows is best understood as a checklist for adding "identity wallet" capabilities (handling Verifiable Credentials natively and as flexible as built-for-purpose identity wallets do) to an existing mobile wallet, whether non-custodial, custodial, or semi-custodial (MPC, multi-sig, etc). ## Minimal Wallet Requirements - Summary @@ -339,8 +337,7 @@ Note: In the Presentation Object that follows (a signed VP in JWT form), the `ve "verifiableCredential": [ { "@context": [ - "https://www.w3.org/2018/credentials/v1", - "https://centre.io/contexts/identity.jsonld" + "https://www.w3.org/2018/credentials/v1" ], "type": ["VerifiableCredential", "KYCAMLCredential"], "credentialSubject": { diff --git a/packages/e2e-demo/README.md b/packages/e2e-demo/README.md index d58db2dd..23c70b8a 100644 --- a/packages/e2e-demo/README.md +++ b/packages/e2e-demo/README.md @@ -92,7 +92,7 @@ The addresses to fill are: ## Contributors -- [Kim Hamilton Duffy](https://github.com/kimdhamilton) ([Centre Consortium](https://centre.io)) -- [Sean Neville](https://github.com/psnevio) ([Circle, Centre, Xdotzero](http://xdotzero.com)) +- [Kim Hamilton Duffy](https://github.com/kimdhamilton) +- [Sean Neville](https://github.com/psnevio) ([Circle, Xdotzero](http://xdotzero.com)) - [Brice Stacey](https://github.com/bricestacey) ([M2 Labs](https://m2.xyz)) - [Matt Venables](https://github.com/venables) ([M2 Labs](https://m2.xyz)) diff --git a/packages/e2e-demo/components/shared/Layout.tsx b/packages/e2e-demo/components/shared/Layout.tsx index 365be030..b61a6750 100644 --- a/packages/e2e-demo/components/shared/Layout.tsx +++ b/packages/e2e-demo/components/shared/Layout.tsx @@ -79,7 +79,7 @@ const Layout: FC = ({ children, title, bgColor }) => { {children}
- ©{new Date().getFullYear()} Centre | Software open sourced + ©{new Date().getFullYear()} Circle Internet Financial Limited | Software open sourced under the MIT license
diff --git a/packages/e2e-demo/pages/demos/issuer/kyc.tsx b/packages/e2e-demo/pages/demos/issuer/kyc.tsx index bd71e19e..6e21a245 100644 --- a/packages/e2e-demo/pages/demos/issuer/kyc.tsx +++ b/packages/e2e-demo/pages/demos/issuer/kyc.tsx @@ -113,7 +113,7 @@ const KycAmlPage: NextPage = ({ {" "} defining the credentials that the issuer can issue and how a wallet can request them. Credential Manifests are a developing standard by - the Decentralized Identity Foundation (of which Centre is a member). + the Decentralized Identity Foundation. 

{JSON.stringify(qrCodeData, null, 4)}
diff --git a/packages/solana/programs/verity/src/lib.rs b/packages/solana/programs/verity/src/lib.rs index 38bd893a..47fa0b68 100644 --- a/packages/solana/programs/verity/src/lib.rs +++ b/packages/solana/programs/verity/src/lib.rs @@ -70,7 +70,7 @@ pub mod verity { // Require that the schema is KYC msg!("Schema: {}", verification_result.schema); - require!(verification_result.schema == "centre.io/credentials/kyc", ErrorCode::InvalidSchema); + require!(verification_result.schema == "", ErrorCode::InvalidSchema); // Recover the address that signed the signature let mut message = Vec::new(); diff --git a/packages/solana/tests/verity.ts b/packages/solana/tests/verity.ts index 3e462a2b..650d9757 100644 --- a/packages/solana/tests/verity.ts +++ b/packages/solana/tests/verity.ts @@ -76,7 +76,7 @@ describe("verity", () => { cluster: "localnet", // 12 bytes subject: alice.publicKey, // 32 bytes expiration, // 8 bytes - schema: "centre.io/credentials/kyc" // 29 bytes + schema: "" // 29 bytes } // Allocate buffer for the message and borsh encode the data. Each type has diff --git a/packages/verite/README.md b/packages/verite/README.md index 86b3b8d5..c78c2500 100644 --- a/packages/verite/README.md +++ b/packages/verite/README.md @@ -44,7 +44,7 @@ lib/utils/ Contains shared utility functions ## Contributors -- [Kim Hamilton Duffy](https://github.com/kimdhamilton) ([Centre Consortium](https://centre.io)) +- [Kim Hamilton Duffy](https://github.com/kimdhamilton) - [Sean Neville](https://github.com/psnevio) ([Xdotzero](http://xdotzero.com)) - [Brice Stacey](https://github.com/bricestacey) ([M2 Labs](https://m2.xyz)) - [Matt Venables](https://github.com/venables) ([M2 Labs](https://m2.xyz)) diff --git a/packages/verite/lib/verifier/result.ts b/packages/verite/lib/verifier/result.ts index c3164be6..08d032a9 100644 --- a/packages/verite/lib/verifier/result.ts +++ b/packages/verite/lib/verifier/result.ts @@ -9,7 +9,7 @@ import type { VerificationResultResponse } from "../../types" * @param contractAddress The VerificationRegistry contract address * @param signerPrivateKey The signer's private key * @param chainId The chain this verification is intended to be used upon - * @param schema The schema that this verification result is for. Defaults to `centre.io/credentials/kyc` for backwards compatability. + * @param schema The schema that this verification result is for, which you can publish at a path such as "/credentials/kyc". Defaults to "". * @returns an object containing a VerificationResult and a signature */ export const verificationResult = async ( @@ -17,7 +17,7 @@ export const verificationResult = async ( contractAddress: string, signerPrivateKey: string, chainId: number, - schema = "centre.io/credentials/kyc" + schema = "" ): Promise => { // A production verifier would integrate with its own persistent wallet, but // this example merely regenerates a new signer trusted signer when needed. diff --git a/packages/verite/test/lib/verifier/presentation-definitions.test.ts b/packages/verite/test/lib/verifier/presentation-definitions.test.ts index 99d8c027..89587db1 100644 --- a/packages/verite/test/lib/verifier/presentation-definitions.test.ts +++ b/packages/verite/test/lib/verifier/presentation-definitions.test.ts @@ -87,9 +87,9 @@ describe("kycAmlPresentationDefinition", () => { it("allows you to customize the list of trusted issuers", () => { // Example where you might only want to accept credentials issued by - // did:web:centre.io or did:web:example.com + // did:web:circle.com or did:web:example.com const definitions = kycAmlPresentationDefinition([ - "did:web:centre.io", + "did:web:circle.com", "did:web:example.com" ]) @@ -147,7 +147,7 @@ describe("kycAmlPresentationDefinition", () => { }, { filter: { - pattern: "^did:web:centre.io$|^did:web:example.com$", + pattern: "^did:web:circle.com$|^did:web:example.com$", type: "string" }, path: ["$.issuer.id", "$.issuer", "$.vc.issuer", "$.iss"], diff --git a/packages/verite/test/lib/verifier/result.test.ts b/packages/verite/test/lib/verifier/result.test.ts index 8c35f842..34fb4f9a 100644 --- a/packages/verite/test/lib/verifier/result.test.ts +++ b/packages/verite/test/lib/verifier/result.test.ts @@ -22,7 +22,7 @@ describe("verificationResult", () => { // signature: "0x19e88da2f358047dc6c2388115c037dc0fa4f6e8af1b3a6ee61af5af1972457c11374071d0e44db96b05eb8fb8a6b85398879b938ca1ff00c99db856bafb885a1c", verificationResult: { // expiration: 1636574690, - schema: "centre.io/credentials/kyc", + schema: "", subject: "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266" } }) @@ -59,12 +59,12 @@ describe("verificationResult", () => { contractAddress, verifierPrivateKey, chainId, - "centre.io/credentials/address" + "" ) expect(result).toMatchObject({ verificationResult: { - schema: "centre.io/credentials/address", + schema: "", subject: "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266" } }) diff --git a/packages/verite/test/lib/verifier/verification-offer.test.ts b/packages/verite/test/lib/verifier/verification-offer.test.ts index 9508ee2b..fc6f90e1 100644 --- a/packages/verite/test/lib/verifier/verification-offer.test.ts +++ b/packages/verite/test/lib/verifier/verification-offer.test.ts @@ -6,7 +6,7 @@ describe("verification offer", () => { const from = "did:web:example.com" const replyUrl = "https://example.com/123" const statusUrl = "https://example.com/status/123" - const trustedAuthorities: string[] = ["did:web:centre.io"] + const trustedAuthorities: string[] = ["did:web:circle.com"] const offer = buildKycVerificationOffer( id, @@ -80,7 +80,7 @@ describe("verification offer", () => { }, { filter: { - pattern: "^did:web:centre.io$", + pattern: "^did:web:circle.com$", type: "string" }, path: ["$.issuer.id", "$.issuer", "$.vc.issuer", "$.iss"], diff --git a/packages/wallet/README.md b/packages/wallet/README.md index 8f8d1084..e8f95d71 100644 --- a/packages/wallet/README.md +++ b/packages/wallet/README.md @@ -43,7 +43,7 @@ The Verite wallet is a sample implementation of core Verite flows, but it makes ## Contributors -- [Kim Hamilton Duffy](https://github.com/kimdhamilton) ([Centre Consortium](https://centre.io)) +- [Kim Hamilton Duffy](https://github.com/kimdhamilton) - [Sean Neville](https://github.com/psnevio) ([Xdotzero](http://xdotzero.com)) - [Brice Stacey](https://github.com/bricestacey) ([M2 Labs](https://m2.xyz)) - [Matt Venables](https://github.com/venables) ([M2 Labs](https://m2.xyz)) diff --git a/packages/wallet/app.json b/packages/wallet/app.json index def8276f..44b01383 100644 --- a/packages/wallet/app.json +++ b/packages/wallet/app.json @@ -17,7 +17,7 @@ "assetBundlePatterns": ["**/*"], "ios": { "supportsTablet": true, - "bundleIdentifier": "io.centre.verity.demo.ios" + "bundleIdentifier": "" }, "android": { "adaptiveIcon": { From 3bed8bb1b0ca153e703bd2c6803e43401d0105fa Mon Sep 17 00:00:00 2001 From: Jess Heron Date: Thu, 12 Oct 2023 14:42:42 -0700 Subject: [PATCH 4/4] Updates instances of repo URL to github.com/circlefin/verite --- packages/docs/blog/2022-03-30-introducing_verite.md | 4 ++-- packages/docs/blog/2022-04-13-crossfunctionality.md | 4 ++-- ...5-09-how_to_create_a_verification_registry_solidity.md | 2 +- ...-15-verifiable_credentials_and_verite_nft_allowlist.md | 2 +- packages/docs/blog/2022-07-27-verification_patterns_2.md | 2 +- packages/docs/docusaurus.config.js | 6 +++--- packages/docs/verite/developers/getting-started.md | 6 +++--- .../verite/developers/issue-a-verifiable-credential.md | 4 ++-- .../tutorials/creating-a-registry-contract-in-solidity.md | 2 +- .../verite/developers/tutorials/solidity-verifications.md | 6 +++--- .../verite/developers/verify-a-verifiable-credential.md | 2 +- packages/docs/verite/patterns/smart-contract-verite.md | 8 ++++---- 12 files changed, 24 insertions(+), 24 deletions(-) diff --git a/packages/docs/blog/2022-03-30-introducing_verite.md b/packages/docs/blog/2022-03-30-introducing_verite.md index 342e297e..cdd731ec 100644 --- a/packages/docs/blog/2022-03-30-introducing_verite.md +++ b/packages/docs/blog/2022-03-30-introducing_verite.md @@ -34,11 +34,11 @@ Despite the standards track for VCs, tooling around the implementation of VCs ha We believe that adoption of VCs is not only about creating good standards. It's also about making the experience of implementation a great one. To this end, Verite has tried to abstract as much of the complexity away as possible. Our documentation dives deep into what's happening behind the scenes, but the Verite library itself feels simple. And that's the goal. -In a sense, Verite is also the canary in the coal mine. It's a test. An experiment. As mentioned above, the secondary goal of Verite's library is to collect community feedback on its implementation. Since the library's release, we've been fortunate enough to receive a number of issues and pull requests in the [Github repository](https://github.com/centrehq/verite). We encourage the community to continue provide feedback. +In a sense, Verite is also the canary in the coal mine. It's a test. An experiment. As mentioned above, the secondary goal of Verite's library is to collect community feedback on its implementation. Since the library's release, we've been fortunate enough to receive a number of issues and pull requests in the [Github repository](https://github.com/circlefin/verite). We encourage the community to continue provide feedback. ## How Can Verite Be Used? -We have a [number of demos available](https://github.com/centrehq/verite/tree/main/packages/e2e-demo/pages/demos) in the Github repository that can serve both as reference points and as inspiration. Verite can be used for just about any VC need. In our demos, you'll find: +We have a [number of demos available](https://github.com/circlefin/verite/tree/main/packages/e2e-demo/pages/demos) in the Github repository that can serve both as reference points and as inspiration. Verite can be used for just about any VC need. In our demos, you'll find: - Basic Credential Issuance - Basic Credential Verification diff --git a/packages/docs/blog/2022-04-13-crossfunctionality.md b/packages/docs/blog/2022-04-13-crossfunctionality.md index ed483648..91cd8bc8 100644 --- a/packages/docs/blog/2022-04-13-crossfunctionality.md +++ b/packages/docs/blog/2022-04-13-crossfunctionality.md @@ -83,7 +83,7 @@ So let's take a little tour of the properties encoded in the "schemas" and manages over time. Each schema is something like a recipe for data points, what engineers call the "data shape" of each credential or token. Take, for example, the [v0.0.1 schema for a -KYCAMLAttestation](https://github.com/centrehq/verite/blob/main/packages/docs/static/definitions/schemas/0.0.1/KYCAMLAttestation) +KYCAMLAttestation](https://github.com/circlefin/verite/blob/main/packages/docs/static/definitions/schemas/0.0.1/KYCAMLAttestation) credential: what you see, in machine-readable script, is a list of the mandatory and optional properties that each credential needs to have, and the "type" of each (string, integer, etc.). Let's walk through some specific properties to @@ -106,7 +106,7 @@ like the others. It is a string, but that string actually contains a link to a second schema; in the example above, taken from the tutorials and examples of the current sample implementation, all the KYCAML credentials point to [this process -definition](https://github.com/centrehq/verite/blob/main/packages/docs/static/definitions/processes/kycaml/0.0.1/usa). +definition](https://github.com/circlefin/verite/blob/main/packages/docs/static/definitions/processes/kycaml/0.0.1/usa). As you can see, this second schema outlines at a high level the real-world process used to arrive at the first schema's data points (in machine-readable format, which can include links to additional machine-readable documents and/or 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 b9d3f5f4..d89ea6c8 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 Circle. 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/circlefin/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-06-15-verifiable_credentials_and_verite_nft_allowlist.md b/packages/docs/blog/2022-06-15-verifiable_credentials_and_verite_nft_allowlist.md index b99d4a0e..473ff356 100644 --- a/packages/docs/blog/2022-06-15-verifiable_credentials_and_verite_nft_allowlist.md +++ b/packages/docs/blog/2022-06-15-verifiable_credentials_and_verite_nft_allowlist.md @@ -86,7 +86,7 @@ Let's get started. You'll need Node.js version 12 or above for this. You'll also From your command line, change into the directory where you keep all your fancy NFT projects. Then, let's clone the example app I built ahead of this tutorial to make our lives easier. ``` -git clone https://github.com/centrehq/verite-minter-allowlist +git clone https://github.com/circlefin/verite-minter-allowlist ``` This is a repository that uses SIWE's base example app and extends it. So what you'll have is a folder for your frontend application, a folder for your backend express server, and a folder for your smart contract-related goodies. 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 fa0d4476..073d24b1 100644 --- a/packages/docs/blog/2022-07-27-verification_patterns_2.md +++ b/packages/docs/blog/2022-07-27-verification_patterns_2.md @@ -80,7 +80,7 @@ You could say that the crypto wallet delegates the encapsulation and signature o 1. Wallet initiates DeFi transaction with dApp. 2. dApp generates a session-specific ephemeral signing key and encoded it in the SIWE message for the wallet to sign. This generated session key will delegate the wallet for future signings, once after wallet vouches it (by signing the CACAO). 3. Once the wallet has signed it and returned it to the dApp, the signature and message are encoded into a compact [CACAO](https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-74.md) session receipt for logging and forensic purposes (if needed). -4. Next the dApp lets the verifier know about the session, by POSTing the receipt to an endpoint (eg. [signIn](https://github.com/centrehq/verite-minter-allowlist/blob/main/backend/src/index.js#L136)). The signed receipt also includes [caveats](https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-74.md#test-cases), a domain-binding, an expiration, and other constraints to secure the delegation and the transfer of the session parameters. +4. Next the dApp lets the verifier know about the session, by POSTing the receipt to an endpoint (eg. [signIn](https://github.com/circlefin/verite-minter-allowlist/blob/main/backend/src/index.js#L136)). The signed receipt also includes [caveats](https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-74.md#test-cases), a domain-binding, an expiration, and other constraints to secure the delegation and the transfer of the session parameters. 5. The verifier saves the CACAO. The verifier only uses this CACAO in the scope of this verification session (to prove the VP signed by the ephemeral key). Once the CACAO verification step is completed, the session object will be updated. 6. Instead of sending the wallet to verify directly with the verifier (as in the previous post), the wallet will submit the VC directly to the dapp (or an agent/service it trusts). The dApp presents the prompt to verify. 7. Wallet submits the bare VC. diff --git a/packages/docs/docusaurus.config.js b/packages/docs/docusaurus.config.js index ff831e7b..c5f2a8ae 100644 --- a/packages/docs/docusaurus.config.js +++ b/packages/docs/docusaurus.config.js @@ -26,7 +26,7 @@ module.exports = { position: "left" }, { - to: "https://github.com/centrehq/verite/tree/main/packages/e2e-demo#readme", + to: "https://github.com/circlefin/verite/tree/main/packages/e2e-demo#readme", label: "Demos", position: "left", target: "_self" @@ -56,7 +56,7 @@ module.exports = { items: [ { label: "Github", - href: "https://github.com/centrehq/verite" + href: "https://github.com/circlefin/verite" } ] } @@ -79,7 +79,7 @@ module.exports = { }, blog: { showReadingTime: true, - editUrl: "https://github.com/centrehq/verite-docs" + editUrl: "https://github.com/circlefin/verite-docs" }, theme: { customCss: require.resolve("./src/css/custom.css") diff --git a/packages/docs/verite/developers/getting-started.md b/packages/docs/verite/developers/getting-started.md index 0ad2970c..561e95e4 100644 --- a/packages/docs/verite/developers/getting-started.md +++ b/packages/docs/verite/developers/getting-started.md @@ -4,10 +4,10 @@ sidebar_position: 1 # Getting Started -Verite has provided several interactive demos as well as sample projects to showcase some use-cases of the Verite standards. The code is freely available on [Github](https://github.com/centrehq/verite). To run all of the demos, you will need code found in two repositories: `verite` and `demo-wallet`. +Verite has provided several interactive demos as well as sample projects to showcase some use-cases of the Verite standards. The code is freely available on [Github](https://github.com/circlefin/verite). To run all of the demos, you will need code found in two repositories: `verite` and `demo-wallet`. -1. Setup and run Verite's [verite](https://github.com/centrehq/verite/blob/main/README.md) -2. Setup and run Verite's [demo-wallet](https://github.com/centrehq/verite/blob/main/packages/wallet/README.md) +1. Setup and run Verite's [verite](https://github.com/circlefin/verite/blob/main/README.md) +2. Setup and run Verite's [demo-wallet](https://github.com/circlefin/verite/blob/main/packages/wallet/README.md) 3. Select a demo in verite to be guided through the steps The `verite` repository also hosts several standalone code samples to assist in developing your own solution. Those samples are located at: diff --git a/packages/docs/verite/developers/issue-a-verifiable-credential.md b/packages/docs/verite/developers/issue-a-verifiable-credential.md index e7583227..a5cb36c7 100644 --- a/packages/docs/verite/developers/issue-a-verifiable-credential.md +++ b/packages/docs/verite/developers/issue-a-verifiable-credential.md @@ -5,7 +5,7 @@ sidebar_position: 3 # Issue a Verifiable Credential -_This tutorial will walk you through issuing verifiable credentials using the verite sdks. For additional context, see [Issuance Flow](/patterns/issuance-flow.md). A complete example of building an issuer is available at our [demo-issuer](https://github.com/centrehq/verite/packages/demo-issuer) demo._ +_This tutorial will walk you through issuing verifiable credentials using the verite sdks. For additional context, see [Issuance Flow](/patterns/issuance-flow.md). A complete example of building an issuer is available at our [demo-issuer](https://github.com/circlefin/verite/packages/demo-issuer) demo._ For the sake of this demo, we will be using Decentralized Identifiers (DIDs) to identify the issuer (you) and subject (the person or entity the credential is about), as well as JSON Web Tokens (JWTs) as the means of signing and verifying the credentials. Strictly speaking, you do not need to use JWTs, but as they are industry-standard and tooling extensively available, they are used throughout this sample implementation. @@ -125,4 +125,4 @@ The subject can then decode the presentation and store their Verifiable Credenti 🎉 That’s it. You have now issued a Verifiable Credential. -You can view this demo as a full working example in our [demo-issuer](https://github.com/centrehq/verite/tree/main/packages/demo-issuer) demo. +You can view this demo as a full working example in our [demo-issuer](https://github.com/circlefin/verite/tree/main/packages/demo-issuer) demo. 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 392e2645..687c363e 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 Circle. 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/circlefin/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/developers/tutorials/solidity-verifications.md b/packages/docs/verite/developers/tutorials/solidity-verifications.md index 51fbb6b6..15bb9516 100644 --- a/packages/docs/verite/developers/tutorials/solidity-verifications.md +++ b/packages/docs/verite/developers/tutorials/solidity-verifications.md @@ -9,7 +9,7 @@ As discussed in the [Smart Contract Patterns](../../patterns/smart-contract-veri Solidity is the language for the Ethereum Virtual Machine. Solidity is the most widely used blockchain programming language. -First, we'll use the example verifier registry contract that Verite has created. [You can find that contract here](https://github.com/centrehq/verite/blob/main/packages/contract/contracts/VerificationRegistry.sol). While this contract should be treated as an example and you should create your own as needed by your specifications when deploying to production, it covers the necessary actions that a verification registry would need to take. +First, we'll use the example verifier registry contract that Verite has created. [You can find that contract here](https://github.com/circlefin/verite/blob/main/packages/contract/contracts/VerificationRegistry.sol). While this contract should be treated as an example and you should create your own as needed by your specifications when deploying to production, it covers the necessary actions that a verification registry would need to take. ## Setting Up Hardhat @@ -49,13 +49,13 @@ Next, you'll need to update your `hardhat.config.js` file. Add the following lin require("@nomiclabs/hardhat-waffle") ``` -In order to work on the smart contract, you'll need to create a `contracts` folder in the root of the project directory. Once you've done that, you can create a new file called `VerificationRegistry.sol`. For simplicity, you can copy over the code from the [example Verite registry contract](https://github.com/centrehq/verite/blob/main/packages/contract/contracts/VerificationRegistry.sol). +In order to work on the smart contract, you'll need to create a `contracts` folder in the root of the project directory. Once you've done that, you can create a new file called `VerificationRegistry.sol`. For simplicity, you can copy over the code from the [example Verite registry contract](https://github.com/circlefin/verite/blob/main/packages/contract/contracts/VerificationRegistry.sol). You'll notice this contract references another contract (an interface contract), and it imports some libraries from OpenZeppelin. So, we need to do two things. We need to install OpenZeppelin, and we need to copy over the interface contract. We'll explain why the interface contract is important momentarily. First, let's install OpenZeppelin's library of contracts: `npm install @openzeppelin/contracts` -Now, you can create a new file in the `contracts` folder called `IVerificationRegistry.sol`. Copy the code [from here](https://github.com/centrehq/verite/blob/main/packages/contract/contracts/VerificationRegistry.sol) and paste it into that file. +Now, you can create a new file in the `contracts` folder called `IVerificationRegistry.sol`. Copy the code [from here](https://github.com/circlefin/verite/blob/main/packages/contract/contracts/VerificationRegistry.sol) and paste it into that file. Before compiling the contracts, check the Solidity version in the contracts. You'll need to make sure it matches the version in the `hardhat.config.js` file. If it doesn't, simply update the config file to match. diff --git a/packages/docs/verite/developers/verify-a-verifiable-credential.md b/packages/docs/verite/developers/verify-a-verifiable-credential.md index df6824ab..b7a253e5 100644 --- a/packages/docs/verite/developers/verify-a-verifiable-credential.md +++ b/packages/docs/verite/developers/verify-a-verifiable-credential.md @@ -97,4 +97,4 @@ await validateVerificationSubmission( ) ``` -You can view this demo as a full working example in our [demo-issuer](https://github.com/centrehq/verite/tree/main/packages/demo-verifier) demo. +You can view this demo as a full working example in our [demo-issuer](https://github.com/circlefin/verite/tree/main/packages/demo-verifier) demo. diff --git a/packages/docs/verite/patterns/smart-contract-verite.md b/packages/docs/verite/patterns/smart-contract-verite.md index 5ec55fdd..e3d21bb2 100644 --- a/packages/docs/verite/patterns/smart-contract-verite.md +++ b/packages/docs/verite/patterns/smart-contract-verite.md @@ -150,7 +150,7 @@ Upon generating a Verification Record, a contract may follow one of two storage In-contract storage involves persisting Verification Records in a manner that associates verifier addresses with all of the Verification Records that a verifier's address has approved, and maps subject addresses to all Verification Records associated with that subject -- exposing no PII or verification result payloads, but providing proof of verification types, timestamps, and expirations that the subject has successfully passed. -An example that executes this pattern is the [VerificationRegistry.sol](https://github.com/centrehq/verite/blob/main/packages/contract/contracts/VerificationRegistry.sol) contract. +An example that executes this pattern is the [VerificationRegistry.sol](https://github.com/circlefin/verite/blob/main/packages/contract/contracts/VerificationRegistry.sol) contract. The off-chain storage pattern involves no such on-chain storage. External oracles and chain scanners can observe the Verification Record events emitted by a contract, but there is no persistence of records on-chain. @@ -182,14 +182,14 @@ The source code examples referenced here are also not intended for production us A reference implementation smart contract that executes Verifier Management, Verification Result validation, and Verification Record persistence is the IVerificationRegistry interface and its VerificationRegistry.sol implementation: - + This registry implementation is used by two examples, PermissionedToken.sol (a verifier submission example) and ThresholdToken.sol (a subject submission example). The test suite leverages hardhat and waffle, and is located in the ‘test’ subdirectory of the above repo: - + An example Dapp with MetaMask integration that uses the ThresholdToken is available here: - +