# Milestone Kickoff: Identity Team 🔖 **URL:** \ **Category:** Developers\ **Created:** [July 12, 2022, 5:15pm UTC](https://forum.celo.org/t/milestone-kickoff-identity-team/3944 "2022-07-12T17:15:12Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![arthurgousset](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.celo.org/arthurgousset/32/11117_2.png) [@arthurgousset](https://forum.celo.org/u/arthurgousset)\ **Post date:** [July 12, 2022, 5:15pm UTC](https://forum.celo.org/t/milestone-kickoff-identity-team/3944/1 "2022-07-12T17:15:12Z")
Hi all, we are the identity team at cLabs: Eela, @isabelle, @Alec and me 👋 As @yerdua mentioned [below](https://forum.celo.org/t/working-in-the-open-at-clabs-milestone-kickoff/3943/2) (👇), next Monday (July 18) we are beginning a ~4.5 week milestone until Thursday, August 18. > [@Working in the open at cLabs: milestone kickoff](https://forum.celo.org/t/working-in-the-open-at-clabs-milestone-kickoff/3943): > > Hey, this is Audrey, one of the engineering leads at cLabs. Today, I’m announcing a new effort towards working in the open, in which each of the engineering teams will regularly share what they’re working on and why it’s important. Internally, we’re working in milestones of about 6 weeks (though, this first one is slightly shorter at 4.5 weeks). A milestone begins with planning, which is followed by several weeks of implementation, and then reflecting on it all before starting again. The first … With this post, we’d like to share some of our current priorities and associated deliverables. Overall, our main priority is rolling out the new federated attestations protocol (”ASv2”) in parallel to the existing validator-run attestation protocol (”ASv1”). You can read more about the new protocol design and motivation in our recently published [CIP51: Federated Attestations Protocol](https://forum.celo.org/t/cip51-federated-attestations-protocol/3942). Our goals for the coming 5 weeks are to: 1. **Complete the ASv2 smart contracts audit process** (incl. responses from auditors) 2. **Refactor ODIS to support [CIP40: Extension to ODIS for Password Hashing](https://github.com/celo-org/celo-proposals/blob/e7dffdde4015b29d71114a14305876e34dffc064/CIPs/cip-0040.md)** 3. **Design a new rate limit for ODIS to support a more intuitive ASv2 onboarding experience** 4. **Circulate protocol design docs specifying user flows (such as onboarding and contact discovery for ASv2)** **What next?** We’d love to hear from you. If this sounds interesting or you have any questions, we greatly appreciate any feedback you might provide, whether good or bad. We are here to listen to you. Feel free to respond below however small or big your message might be! Thank you 🙏 Also feel free to respond below if you are interested in participating in our ASv2 private beta release 🚀 ---
**Author:** ![DonaFlorinda](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.celo.org/donaflorinda/32/7416_2.png) [@DonaFlorinda](https://forum.celo.org/u/DonaFlorinda)\ **Post date:** [August 9, 2022, 10:28pm UTC](https://forum.celo.org/t/milestone-kickoff-identity-team/3944/2 "2022-08-09T22:28:21Z")
hi arthur! Having neurons collapsing here trying to understand ODIS - Oblivious Decentralized Identifier Service, - Can you enlight us examples of usages for this Phone-number Privacy Protocol? - Could we “chain” our phone-number to a wallet-address (pubkey)? > **[Oblivious Decentralized Identifier Service (ODIS) | Celo Documentation](https://docs.celo.org/celo-codebase/protocol/odis)** > > The Oblivious Decentralized Identifier Service (ODIS) allows for privacy preserving phone number mappings, password hardening, and other use cases by implementing a rate limited oblivious pseudorandom function (OPRF). Thx! ---
**Author:** ![arthurgousset](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.celo.org/arthurgousset/32/11117_2.png) [@arthurgousset](https://forum.celo.org/u/arthurgousset)\ **Post date:** [August 12, 2022, 1:15pm UTC](https://forum.celo.org/t/milestone-kickoff-identity-team/3944/3 "2022-08-12T13:15:11Z")
Thanks for your questions @DonaFlorinda! I agree with you, we need to do a lot better explaining how our products work and how they can be used 👍 Thank you for reminding us, this is definitely on our mind. > Can you enlight us examples of usages for this Phone-number Privacy Protocol? I’m not sure I can enlighten you (😄), but I’m happy to give you some TLDRs and illustrative use cases. **Concept 1** : Adding a `salt` to a _phone number_\* to better store it. - You can read more about the concept of `salts` here: [Adding Salt to Hashing: A Better Way to Store Passwords](https://auth0.com/blog/adding-salt-to-hashing-a-better-way-to-store-passwords/) - TLDR: They allow you to store `strings` (phone numbers for example) in a more secure way - (_Detail you can ignore, but adding for completeness_) A `pepper` is like a `salt` but secret. **Concept 2** : Using ODIS to generate `peppers` to better store _phone numbers_\* on the blockchain - We use ODIS as a product to generate `peppers` so we can encrypt _phone numbers_\* and store them on the blockchain (among other use cases) - ODIS also serves as a rate-limit to stop malicious actors from requesting too many `peppers` (which would make `peppers` pointless to start with) **Concept 3** : Using a registry to map encrypted _phone numbers_\* to Celo addresses - We use a smart contract ([Attestations.sol](https://github.com/celo-org/celo-monorepo/blob/8da97e9882eeae27322f0c48bdfbe0417fe09f27/packages/protocol/contracts/identity/Attestations.sol#L76)) to store mappings from _phone numbers_\* (encrypted with `peppers` generated by ODIS) to Celo addresses. To answer your question: > Could we “chain” our phone-number to a wallet-address (pubkey)? _Yes_, you can create a _pointer_ from your phone number to your Celo address on the blockchain, so anyone who’d like to know which Celo address belongs to you, can check that in the registry linked above. You can think of this like a _pointer_, but it is not capable of signing transactions on your behalf. Signing and submitting transactions is still performed using private keys under the hood. **Footnote** : \*_Any `string`, for that matter._ ---
**Author:** ![DonaFlorinda](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.celo.org/donaflorinda/32/7416_2.png) [@DonaFlorinda](https://forum.celo.org/u/DonaFlorinda)\ **Post date:** [August 24, 2022, 8:03pm UTC](https://forum.celo.org/t/milestone-kickoff-identity-team/3944/4 "2022-08-24T20:03:17Z")
Cool! Thanks for the explanation. Bringing in some other questions, 🤓 - How much it cost to call the “Attestator” contract for the peeper? - celocli identity:current-attestation-services runs forever, some Celo is also needed to check it? - All elected Validators are Attestators or there is a single address for this smart-contract? - If many, it means there are many deploys of this same contract? Trying to figure out. - What happens after we read the pepper, how we “match” it to the phone? - Are the phones attested, like a SMS verification to prove it is from who publishes it? - Can I register as many phones as I can pay to store this data? Sorry for the storm of questions… sounds super interesting how to store encrypted data on-chain and (somehow) also the pepper hash, but I still need a pull here to see the full mechanism providing this match. Gracias ---
**Author:** ![arthurgousset](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.celo.org/arthurgousset/32/11117_2.png) [@arthurgousset](https://forum.celo.org/u/arthurgousset)\ **Post date:** [August 26, 2022, 7:26pm UTC](https://forum.celo.org/t/milestone-kickoff-identity-team/3944/5 "2022-08-26T19:26:58Z")
Hi all 👋 Our recent 5 week milestone is finished and we are following up to share what we accomplished and learnt. Our goals for the past 5 weeks were: > [@arthurgousset](#): > > **Complete the ASv2 smart contracts audit process** (incl. responses from auditors) > > This matters because all Celo core contracts have to be audited according to the [release process](https://docs.celo.org/community/release-process/smart-contracts#promotion-process) and both the [`FederatedAttestations.sol`](https://github.com/celo-org/celo-monorepo/blob/ASv2/packages/protocol/contracts/identity/FederatedAttestations.sol) and updated [`Escrow.sol`](https://github.com/celo-org/celo-monorepo/blob/ASv2/packages/protocol/contracts/identity/Escrow.sol) smart contracts are central to the value proposition of the new ASv2 protocol. ✅ The engineering team completed the smart contract security audit with [Hacken.io](http://Hacken.io). You can find the [audit report here](https://hacken.io/wp-content/uploads/2022/08/CLABS_04072022_SCAudit_Report2-5.pdf). > [@arthurgousset](#): > > **Refactor ODIS to support [CIP40: Extension to ODIS for Password Hashing](https://github.com/celo-org/celo-proposals/blob/e7dffdde4015b29d71114a14305876e34dffc064/CIPs/cip-0040.md)** > > This matters because the ODIS refactor is blocking > > (i) the ODIS updates for ASv2 ([CIP51: Federated Attestations Protocol](https://forum.celo.org/t/cip51-federated-attestations-protocol/3942)), and > > (ii) the launch of PEAR **🍐** ([Pin Encrypted Account Recovery](https://docs.celo.org/celo-codebase/protocol/identity/encrypted-cloud-backup)) 🟡 The engineering team largely completed the ODIS v2.0.0 refactor. You can find their changes in the following pull request: [ODIS 2.0.0 #9693](https://github.com/celo-org/celo-monorepo/pull/9693). The engineering team is currently performing the last stages testing in QA/Review, which is why the PR hasn’t yet been merged. We are being somewhat conservative in our self-evaluation and will not consider this stated goal fully accomplished. Our main take-away for future milestones is to insist on better “definitions of done”. For instance to better define the meaning of “_refactoring ODIS” in this case._ > [@arthurgousset](#): > > **Design a new rate limit for ODIS to support a more intuitive ASv2 onboarding experience** > > This matters because an intuitive rate limit when querying ODIS peppers, is a core user experience promise we are making to adopters of the new ASv2. ✅ The engineering team designed a new rate limit for ODIS using the `OdisPayments.sol` contract. You can find the code changes in the following pull request: [On-chain ODIS for quota #9710](https://github.com/celo-org/celo-monorepo/pull/9710). The contract is currently undergoing a security audit with [Verilog](https://www.verilog.solutions/#/audit). > [@arthurgousset](#): > > **Circulate protocol design docs specifying user flows (such as onboarding and contact discovery for ASv2)** > > This matters because intuitive user onboarding and contact discovery experiences are key requirements shared with us by prospective ASv2 issuers. By circulating these user flows, we aim to ensure our vision for these features aligns with the needs of prospective ASv2 issuers. ✅ The engineering team drafted very detailed user flows using the [Mermaid diagramming language](https://mermaid-js.github.io/mermaid/#/). We will share the user flows with early ASv2 adopters to ensure all parties are aligned. ---
**Author:** ![arthurgousset](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.celo.org/arthurgousset/32/11117_2.png) [@arthurgousset](https://forum.celo.org/u/arthurgousset)\ **Post date:** [August 26, 2022, 7:53pm UTC](https://forum.celo.org/t/milestone-kickoff-identity-team/3944/6 "2022-08-26T19:53:23Z")
Thanks for the questions @DonaFlorinda! Going through your questions below 🙂 > [@DonaFlorinda](#): > > How much it cost to call the “Attestator” contract for the peeper? It _costs_ ~$0.001 to query peppers. > [@DonaFlorinda](#): > > celocli identity:current-attestation-services runs forever, some Celo is also needed to check it? No, you shouldn’t need CELO to run this command. It works on my end, see screenshot below. ![image](https://us1.discourse-cdn.com/flex020/uploads/celo/original/2X/5/5b604b52c8e81d01fa637604d00ff6e8a8f46db6.png) Try this: ```bash celocli identity:current-attestation-services --node https://forno.celo.org ``` If you’re interested, you can find some specific worked examples for using the CLI for identity commands here: - [Identity Celo CLI Commands · GitHub](https://gist.github.com/0xarthurxyz/bf111f507461f96cee62d2c436806da8#current-attestation-services) > [@DonaFlorinda](#): > > All elected Validators are Attestators or there is a single address for this smart-contract? > If many, it means there are many deploys of this same contract? Trying to figure out. There is a single smart contract called Attestations.sol. You can find the **current** Attestations `implementation` and `proxy` contracts for it here: - `implementation` contract: [0x1EC3366D384ee7996F2F70B67A65C5d54Ce96040](https://celoscan.io/address/0x1ec3366d384ee7996f2f70b67a65c5d54ce96040) - `proxy` contract: [0xdC553892cdeeeD9f575aa0FBA099e5847fd88D20](https://celoscan.io/address/0xdc553892cdeeed9f575aa0fba099e5847fd88d20) For context: > Implementation contract implements some business logic users wants to interact with, but instead of interacting directly with the contract, they call functions from the proxy contract. As a result of such chaining, it becomes possible to **swap the implementation contract** with a different one Source: [Upgradeable proxy contract from scratch](https://medium.com/coinmonks/upgradeable-proxy-contract-from-scratch-3e5f7ad0b741) ![image](https://us1.discourse-cdn.com/flex020/uploads/celo/original/2X/1/1fa112eda5c2b7741b2b51f948370f2235718420.jpeg) > [@DonaFlorinda](#): > > What happens after we read the pepper, how we “match” it to the phone? You hash the the pepper and plain text phone number using the following pattern `{prefix}{e164_phone_number}{separator}{pepper}` and look for the associated mapping in the Attestations.sol contract. For example, for a phone number `+123456789` and a pepper `123abc` you would hash `tel://+123456789__123abc`. You can checkout the follow illustrative implementation to see the exact contract calls: - Github: [critesjosh / register-number](https://github.com/critesjosh/register-number) > [@DonaFlorinda](#): > > Are the phones attested, like a SMS verification to prove it is from who publishes it? Yes, randomly selected validators are sending SMSs to users to verify phone number ownership. > [@DonaFlorinda](#): > > Can I register as many phones as I can pay to store this data? Yes, assuming you can prove ownership over every phone number you want to map. ---
**Author:** ![arthurgousset](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.celo.org/arthurgousset/32/11117_2.png) [@arthurgousset](https://forum.celo.org/u/arthurgousset)\ **Post date:** [August 30, 2022, 6:05pm UTC](https://forum.celo.org/t/milestone-kickoff-identity-team/3944/7 "2022-08-30T18:05:21Z")
You can follow us in the next milestone below: > [@Milestone Kickoff: Identity Team bookmark \[Aug-Sep\]](https://forum.celo.org/t/milestone-kickoff-identity-team-aug-sep/4262/1): > > Hi all, we are the identity team at cLabs: Eela, @isabelle, @Alec and me 👋 > > Last Wednesday (August 24) we began a new ~6 week milestone, which will take us to Wed, September 28. With this post, we’d like to share some of our current priorities and associated deliverables. > > Overall, our main priority continues to be **launching the new federated attestations protocol (”ASv2”)** in parallel to the existing validator-run attestation protocol (”ASv1”). You can read more about the new protocol design and motivation in [CIP51: Federated Attestations Protocol](https://forum.celo.org/t/cip51-federated-attestations-protocol/3942).