(Feature) Use of ERC780 for storing attestations

[Janther]

• What is it? (leave one option)

  • New (Feature) request (i.e. some nice-to-have feature is missing)

• What feature are you talking about? ERC780 is a standard proposed by the uPort team for storing attestations on the blockchain. By using the Ethereum Claims Registry proposed in the standard every claim about an identity should be put here (address, phone number, etc...). The registry has 3 key main words:

  • Issuer: in this case the ProofOfPhysicalAddress.sol address.
  • Subject: the User address.
  • Claim: a key/value pair that can be whatever we think should be descriptive enough and unique to prove the validity of the information.

• What is proposed feature? Once an address is confirmed the ProofOfPhysicalAddress.sol contract will make a Claim against the User with information about the confirmed address. I propose that we use the following key/value definitions:

  • key: the keccak256 of the address that a person is querying.
  • value: the timestamp of the confirmation (bytes8, still 24 bytes for extra info that we feel should be here.)

• Additional information

The use of the Claims Registry would allow other contracts developed by the POA Network to make claims of verified information.

With this registry, the Issuer can add, update or delete Claims against a Subject. However the Subject is the owner of its identity, so it can delete Claims if it wants to be forgotten however it will need to know the issuer address, its own address, and the key in order to remove that from the registry.

[pablofullana]

Hi @Janther, glad you brought this one to the table. Using a standard is one of our next steps down the road. And, specifically, ERC780 is the standard I was paying closest attention to.

Moreover, @fvictorio is currently working on a spike for integrating PoPA and uPort, enabling the first one to become an identity provider of the latter. So everything seems to be aligned.

I'm on board with discussing this further (if required) and working on it as we see fit.

[phahulin]

Few questions from my side:

1. Shall we have a "POA Registry" ERC780-contract shared by all proof-of-... dapps or separate ones?
2. Should we think about making PoPA contract upgradable or setting a proxy, so that issuer stays the same for all the time, or intentionally use different issuers in case of upgrade
3. We'll need to add a function to remove address. On PoPA-side it should also trigger registry, and registry should trigger PoPA in case subject is removing his own address (since this is allowed by ERC780).

[phahulin]

4. We should also take care about reconfirmations, maybe use one of those 24 extra bytes we have in values to set/remove a flag (1 byte) - address is confirmed/being reconfirmed

[fvictorio]

I'm working on a simple proof of concept for integrating uPort with PoPA. For the time being, I will just make the server attest that some ethereum address has some physical address. I think we can then improve that in subsequent iterations.

I'm not really sure if the registry where uPort saves attestations is an ERC780. I'd bet it is (after all, they are the authors), but I'm not 100% sure.

Issuer: in this case the ProofOfPhysicalAddress.sol address.

I don't know if this can be done using uPort, at least right now, although it would be nice. As far as I know, an issuer is a uPort ID, which in turn is the address of a Proxy contract created by uPort. Maybe there is some way around it; we should keep it in mind.

[pablofullana]

@fvictorio and myself had a quick chat on your questions @phahulin. Our thoughts below:

1. Shall we have a "POA Registry" ERC780-contract shared by all proof-of-... dapps or separate ones?

One single registry sounds good. Moreover, shall we consider deploying the ERC780-contract to a POA network instead of using the uPort one, does this make sense?

2. Should we think about making PoPA contract upgradable or setting a proxy, so that issuer stays the same for all the time, or intentionally use different issuers in case of upgrade

Same issuer makes more sense to us, if possible. Not sure about implementation details/concerns.

3. We'll need to add a function to remove address. On PoPA-side it should also trigger registry, and registry should trigger PoPA in case subject is removing his own address (since this is allowed by ERC780).

Right, we need to consider the removal of an address, which may be triggered from both parties. We could discuss removals on it's own thread since it may be not that trivial.

4. We should also take care about reconfirmations, maybe use one of those 24 extra bytes we have in values to set/remove a flag (1 byte) - address is confirmed/being reconfirmed

Agreed. Re-confirmations has to be added to the pipeline as well. But I think we should discuss re-confirmations on it's own issue once created.

---

@phahulin do these cover your questions? @Janther we'd like to know your thoughts as well, we may be missing something. @rstormsf feel free to jump into the discussion as well.

[Janther]

Nice questions. Here is my input:

1. Shall we have a "POA Registry" ERC780-contract shared by all proof-of-... dapps or separate ones?

I believe that one registry for everything PoA Network related is the way to go. Even though we could use uPort's registry, I think that we should deploy a contract.

2. Should we think about making PoPA contract upgradable or setting a proxy, so that issuer stays the same for all the time, or intentionally use different issuers in case of upgrade

I like the idea of a proxy but also, every PoA dapp should have its own issuer contract. If you are considering upgrading the contract I propose to have at least 1 byte on the value for the version of the contract that we are using for that claim.

3. We'll need to add a function to remove address. On PoPA-side it should also trigger registry, and registry should trigger PoPA in case subject is removing his own address (since this is allowed by ERC780).

Removal of address is a big thing specially since the legislation of the EU gives everybody the right to be digitally "forgotten". Also, the PoPA dapp should be concerned with confirming addresses so I don't see why would we want triggers for somebody removing their address. That can be done easily though since the registry emits an event with the removal of a claim.

4. We should also take care about reconfirmations, maybe use one of those 24 extra bytes we have in values to set/remove a flag (1 byte) - address is confirmed/being reconfirmed

Since anybody can make Claims, a 3rd party can simply make a claim about a User's Physical Address needing a reconfirmation. Then to see if a Physical Address is confirmed, the dapp only needs to check the registry if the address has a Claim for that address and then check if any of the registered 3rd parties has requested a reconfirmation.

[phahulin]

I post it here, because I think it's not specific to any of the individual issues.

So, are we going to rewrite the existing schema? - we drop the existing PoPA contract (only store confirmation codes there), keep addresses in the ERC780 registry by their hash, keep confirmation status there (in value) and PoPA DApp serves as one of agents that is "allowed" to update the registry, correct? What we're losing here is the ability to list addresses by user, if I'm not missing something it's not possible to do in ERC780. We can keep PoPA contract as a separate storage for an array of plain text addresses, but we'll need to keep it in sync with the registry.

[oed]

Hey all, thanks for looking at the claims registry :) Here are some of my thoughs:

1. Shall we have a "POA Registry" ERC780-contract shared by all proof-of-... dapps or separate ones?

I believe that one registry for everything PoA Network related is the way to go. Even though we could use uPort's registry, I think that we should deploy a contract.

The idea of ERC780 is to have one central registry for the entire blockchain. So there should be no need to deploy a separate one for PoA apps.

One single registry sounds good. Moreover, shall we consider deploying the ERC780-contract to a POA network instead of using the uPort one, does this make sense?

Deploying the registry to new blockchains makes a lot of sense. We are looking at using the deployment method suggested for ERC820 basically create a single tx that can be "replayed" to all chains. This means that the registry will have the same address on all different EVM based blockchains.

2. Should we think about making PoPA contract upgradable or setting a proxy, so that issuer stays the same for all the time, or intentionally use different issuers in case of upgrade

This is interesting and I've had similar thoughts for other applications. Lmk if you come up with something nice!

I'm not really sure if the registry where uPort saves attestations is an ERC780. I'd bet it is (after all, they are the authors), but I'm not 100% sure.

ERC780 is uports solution for on-chain claims. Currently most claims in the uport protocol live off-chain for privacy reasons. Putting claims on chain also has potential legal implications, so we are mostly very careful with what we use on-chain claims for.

Issuer: in this case the ProofOfPhysicalAddress.sol address.

I don't know if this can be done using uPort, at least right now, although it would be nice. As far as I know, an issuer is a uPort ID, which in turn is the address of a Proxy contract created by uPort. Maybe there is some way around it; we should keep it in mind.

Nope he is correct. The ProofOfPhysicalAddress.sol address will be the issuer in this case. ERC780 always makes the msg.sender the issuer and in this case this would be the PoPA contract.

cc @Janther @pablofullana @phahulin @fvictorio

[fvictorio]

Hey @oed, thanks for chiming in.

Nope he is correct. The ProofOfPhysicalAddress.sol address will be the issuer in this case. ERC780 always makes the msg.sender the issuer and in this case this would be the PoPA contract.

That would be the case if the ProofOfPhysicalAddress would call the ERC780 contract directly, right?. My comment was because we are thinking about using the uPort app for attesting the physical address. In that case, we would need a uPort app that necessarily would have a different address that the PoPA contract. Am I missing something here?

[oed]

@fvictorio

That would be the case if the ProofOfPhysicalAddress would call the ERC780 contract directly, right?. My comment was because we are thinking about using the uPort app for attesting the physical address. In that case, we would need a uPort app that necessarily would have a different address that the PoPA contract. Am I missing something here?

I thought the purpose of PoPA was that you as a third party verify the address of the user. So I don't think it makes sense for the uport user to publish this claim. So the PoPA infra would call the PoPA contract which adds the claim to the registry. Or am I totally off here? The PoPA service could also issue an off-chain claim to the uport identity that the user could selectively disclose to anyone it chooses.

[fvictorio]

The PoPA service could also issue an off-chain claim to the uport identity that the user could selectively disclose to anyone it chooses.

Maybe that's what I was aiming to (I'm still getting my head around uPort).

My idea was that PoPA somehow attested (using uport-connect) the physical address of the user (after it was validated using the dapp). I now realize that this is an off-chain claim; I thought all uPort claims were saved on-chain before reading your previous comment.

So these are the options, as far as I understand it:

• Do nothing. The PoPA contract has the information about the user's physical address. Note that this means that the user's information is on-chain.
• Send the claim to the ERC780 contract. This option is a little fuzzy in my mind, I don't know how much change it would imply. Would the information still be in the PoPA contract? What would be the claim's content exactly?
• Use uPort for attesting the physical address about the user. The claim would be kept off-chain, but since the PoPA contract still has that information on-chain, the (potential) privacy concerns are still there. Honestly, I don't know if that's really an issue here. Surely @rstormsf or @phahulin can answer that.

Does that make sense? Is there some alternative I'm missing?

[oed]

@fvictorio Sounds like you are about right.

The benefit of putting the claim in the claims registry is that a user could query the logs to see all claims that are associated with them. So different PoX dapps would share the same data store.

[phahulin]

@fvictorio I'm also unsure about the end goal here

Surely @rstormsf or @phahulin can answer that.

maybe @pablofullana or @igorbarinov can help us with this - should we keep physical addresses publicly available on-chain in plain text? This also relates to https://github.com/poanetwork/poa-popa/issues/90

[igorbarinov]

Great discussion, guys. Really enjoying reading it.

@phahulin for validators and users of our reference dapp the address data will be onchain. E.g. for validators it will additional source of data for http://validators.poa.network/ for each attestation and for a page of each individual validator https://poaexplorer.com/validators/address/0x6e4f8fc73b93ba5160fadf914603a590d4676494

for the third-party use case, we could have an additional ZKP-style of attestation. We should figure out a use case for that first tho

[fvictorio]

If that's the case, and if we want to use the ERC780 contract, then I figure we should do something like this:

• In the same contract method that confirms the physical address, make the claim to the ERC780 contract.
• We can use any ERC780 registry while this is being implemented and tested, but when the uPort folks make their deploy (using that technique for having the same addresses in all chains) we should move to that address. We should also deploy it in the POA chain.

[phahulin]

Thing to notice here is that while PoPA contract can call ERC780 contract to add/update/remove a claim, user can remove his claim from ERC780 registry directly, bypassing PoPA, in which case list of addresses will get out of sync

[oed]

for the third-party use case, we could have an additional ZKP-style of attestation

Would love to hear if you make progress on this in the future

We can use any ERC780 registry while this is being implemented and tested, but when the uPort folks make their deploy (using that technique for having the same addresses in all chains) we should move to that address. We should also deploy it in the POA chain.

I finished this yesterday. See here for how to deploy the contract to your network. Address is always 0xaca1bcd8d0f5a9bfc95aff331da4c250cd9ac2da.

[fvictorio]

I just deployed the registry to Sokol. It should be at that address (0xaca1bcd8d0f5a9bfc95aff331da4c250cd9ac2da).

[fvictorio]

If someone sends ether to 0x3e5a951e84df3ca6432a1d1f03638e84152f3388 in POA network, I will send the transaction that creates the contract there too.

0.01 POA's ETH should be enough.

[phahulin]

@fvictorio could you also deploy ERC780 registry contract to Core? Is 0x3e5a951e84df3ca6432a1d1f03638e84152f3388 still relevant? I can send you some POA.

[fvictorio]

@phahulin I think we need to deploy all the contracts with truffle migrate, don't we?

[phahulin]

@fvictorio will ERC780 have correct address (0xaca1bcd8d0f5a9bfc95aff331da4c250cd9ac2da) if we deploy it with truffle?

[fvictorio]

No, it won't. But if we deploy it to that address (and that would be a good idea, in my opinion) then we'll need to modify the truffle migration files. Not a big deal, but we need to keep that in mind.

[fvictorio]

ERC780 deployed to Core: https://poaexplorer.com/address/search/0xaca1bcd8d0f5a9bfc95aff331da4c250cd9ac2da