Conversation
yehjxraymond
left a comment
yehjxraymond
left a comment
There was a problem hiding this comment.
Hey Adam, great work on the ADR! It is very well thought out and structured. I'm just uncomfortable in the use of tx.origin because of the controversy surrounding it. Wonder if you prefer to deal with that discussion in this PR or would you like this PR to be merged first before we append this document again after our discussion?
| - This presents the opportunity to verify the issuer against the `ethereumAddress` associated with this `publicKey`. | ||
| From above: `ethereumAddress: 0xb9c5714089478a327f09197987f16f9e5d936e8a` | ||
| - In order to verify the issuer we need some proof that the issuer actually controls this address. | ||
| - If the `tx.origin` that sent the transaction to issue the document in question matches the `ethereumAddress` associated with the `publicKey` the issuer may be verified. |
There was a problem hiding this comment.
I think the idea of using tx.origin is quite controversial for multiple reason:
- tx.origin has been associated to multiple vulnerabilities and there are calls to deprecate the usage of tx.origin
- the use of tx.origin breaks the general composability of Ethereum contracts
These are explained in greater details here
I will suggest the use of the public key directly to prove the identity claim.
I'm not familiar of the topic but is there a way for non-EOA to control a DID or DID document to hold arbitrary paylod? Because if so, we can possibly have the DID document directly claiming the ownership of the document store without signatures (similar to DNS approach where the DNS record claims ownership of document store)
That, or we can figure a method for us to sign something with the private key so that the receiver of the document may verify the signature indeed came from the owner of the DID.
There was a problem hiding this comment.
Thanks very much for the review and feedback. The concerns regarding tx.origin as raised are generally in the context of Solidity and use within smart contracts, which I completely agree with.
However externally, traversing blocks etc from an off-chain perspective, I am not sure these concerns still hold? Also, if tx.origin were removed from Solidity that would not affect our implementation as by design all Ethereum transaction receipts (at least at present) require an origin (From) and we are not using Solidity to get this.
If we were to note the certificate store we would then need to prove ownership of it somehow, ie. the owner of the contract but that can be changed and not tightly bound to the specific certificate that is being verified, or by verifying the sender of some transaction related to that contract which brings us to tx.origin again.
I agree signing the certificate directly would alleviate this problem which is the separate ADR I am (slowly sorry) drafting, but would require some further work to integrate for issuers.
This felt the shortest path to integrate another Identity Proof :)
Please let me know your thoughts! Thanks!
There was a problem hiding this comment.
Regarding merging that is up to you! If you feel this a suitable v1 for example we can merge in and then continue this discussion for the next iteration. Up to you guys :)
2 participants
No description provided.