{"action":"created","issue":{"url":"https://api.github.com/repos/ethereum/EIPs/issues/712","repository_url":"https://api.github.com/repos/ethereum/EIPs","labels_url":"https://api.github.com/repos/ethereum/EIPs/issues/712/labels{/name}","comments_url":"https://api.github.com/repos/ethereum/EIPs/issues/712/comments","events_url":"https://api.github.com/repos/ethereum/EIPs/issues/712/events","html_url":"https://github.com/ethereum/EIPs/pull/712","id":257207367,"node_id":"MDExOlB1bGxSZXF1ZXN0MTQwNzAwNDQ4","number":712,"title":"[WIP] Add eth_signTypedData as a standard for machine-verifiable and human-readable typed data signing with Ethereum keys","user":{"login":"LogvinovLeon","id":6204356,"node_id":"MDQ6VXNlcjYyMDQzNTY=","avatar_url":"https://avatars1.githubusercontent.com/u/6204356?v=4","gravatar_id":"","url":"https://api.github.com/users/LogvinovLeon","html_url":"https://github.com/LogvinovLeon","followers_url":"https://api.github.com/users/LogvinovLeon/followers","following_url":"https://api.github.com/users/LogvinovLeon/following{/other_user}","gists_url":"https://api.github.com/users/LogvinovLeon/gists{/gist_id}","starred_url":"https://api.github.com/users/LogvinovLeon/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/LogvinovLeon/subscriptions","organizations_url":"https://api.github.com/users/LogvinovLeon/orgs","repos_url":"https://api.github.com/users/LogvinovLeon/repos","events_url":"https://api.github.com/users/LogvinovLeon/events{/privacy}","received_events_url":"https://api.github.com/users/LogvinovLeon/received_events","type":"User","site_admin":false},"labels":[{"id":290507092,"node_id":"MDU6TGFiZWwyOTA1MDcwOTI=","url":"https://api.github.com/repos/ethereum/EIPs/labels/ERC","name":"ERC","color":"d4c5f9","default":false}],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":198,"created_at":"2017-09-12T22:52:46Z","updated_at":"2018-12-18T23:48:24Z","closed_at":"2018-06-09T19:19:15Z","author_association":"CONTRIBUTOR","pull_request":{"url":"https://api.github.com/repos/ethereum/EIPs/pulls/712","html_url":"https://github.com/ethereum/EIPs/pull/712","diff_url":"https://github.com/ethereum/EIPs/pull/712.diff","patch_url":"https://github.com/ethereum/EIPs/pull/712.patch"},"body":"https://github.com/0xProject/EIPs/blob/master/EIPS/eip-signTypedData.md"},"comment":{"url":"https://api.github.com/repos/ethereum/EIPs/issues/comments/448415205","html_url":"https://github.com/ethereum/EIPs/pull/712#issuecomment-448415205","issue_url":"https://api.github.com/repos/ethereum/EIPs/issues/712","id":448415205,"node_id":"MDEyOklzc3VlQ29tbWVudDQ0ODQxNTIwNQ==","user":{"login":"Recmo","id":4532328,"node_id":"MDQ6VXNlcjQ1MzIzMjg=","avatar_url":"https://avatars2.githubusercontent.com/u/4532328?v=4","gravatar_id":"","url":"https://api.github.com/users/Recmo","html_url":"https://github.com/Recmo","followers_url":"https://api.github.com/users/Recmo/followers","following_url":"https://api.github.com/users/Recmo/following{/other_user}","gists_url":"https://api.github.com/users/Recmo/gists{/gist_id}","starred_url":"https://api.github.com/users/Recmo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Recmo/subscriptions","organizations_url":"https://api.github.com/users/Recmo/orgs","repos_url":"https://api.github.com/users/Recmo/repos","events_url":"https://api.github.com/users/Recmo/events{/privacy}","received_events_url":"https://api.github.com/users/Recmo/received_events","type":"User","site_admin":false},"created_at":"2018-12-18T23:48:24Z","updated_at":"2018-12-18T23:48:24Z","author_association":"NONE","body":"@wighawag \r\n\r\n> The newest version of the code at https://github.com/wighawag/eip712-origin is now using \"_originHash\" in the application specific data.\r\n\r\nI'm not entirely sure what the goal is here. In general, per-signature data can be added by creating an envelope:\r\n\r\n```\r\nstruct Envelope {\r\n    bytes32 originHash;\r\n    Mail contents;\r\n}\r\n```\r\n\r\nStandardizing on some per-signature data from the user-agent is interesting and worth considering, perhaps as a follow-up EIP.\r\n\r\nNote that the example can also be done using the existing domain separator:\r\n\r\n```solidity\r\n    function approve(bytes origin) {\r\n       approvedOrigins[mail.from.wallet][hash(EIP712Domain({\r\n            name: \"Ether Mail\",\r\n            version: '1',\r\n            chainId: 1,\r\n            origin: origin,\r\n            // verifyingContract: this\r\n            verifyingContract: 0xCcCCccccCCCCcCCCCCCcCcCccCcCCCcCcccccccC\r\n        }))] = true;\r\n   }\r\n\r\n     function verify(bytes32 domain, MailWithOrigin mail, uint8 v, bytes32 r, bytes32 s) internal view returns (bool) {\r\n        require(approvedOrigins[mail.from.wallet][domain], \"origin not approved by mail sender\");\r\n        bytes32 digest = keccak256(abi.encodePacked(\r\n            \"\\x19\\x01\",\r\n            domain,\r\n            hash(mail)\r\n        ));\r\n        return ecrecover(digest, v, r, s) == mail.from.wallet;\r\n}\r\n```\r\n\r\nPS: In your example contract you have `& 2^256-1`. Note that `^` means xor in Solidity and not exponentiation, which is `**`.\r\n\r\n> You either have a native wallet app that get signature request from other native apps, in which case the operating system could provide the origin (whatever the os can provide to identify the app that requested a signature) to the wallet.\r\n\r\nThis is a great generalization of the origin concept. But I'm not sure what information an OS can provide that is not easily spoofed by that requestor. \r\n"}}
{"actor":{"display_login":"Recmo"}}