A note on iframes sharing secrets

Usecases
1

This post is to document a continues discussion we have had when trying to use secrets from both a Cheque or Ticket issuer and the Attestation issuer, in the browser. This for example occurs in the Devcon use-case when a user on a third-party website wishes to prove that he/she is in possession of a Devcon ticket, and an associated email Attestation to the same email. Basically the user needs to prove that he knows the secret of the Devcon ticket and the secret of the email Attestation and return this proof to the third party website. The secrets for the Devcon ticket is stored in a cookie for devcon.org and the secret for the email Attestation is stored in a cookie for attestation.id. To compute such a proof the following happens:

  1. The third part website takes contact to the devcon.org iframe.
  2. The devcon.org iframe then takes contact to the attestation.id iframe and returns its secret to the devcon.org iframe.
  3. The devcon.org iframe now computes the proof (and can get it signed by MetaMask) and returns this to the third party site's frame.

Since the secret of attestation.id only can be used to leak a user's email, it is not a risk to return it to devcon.org since this already knows the user's email if it has issued a ticket to this user. If the other order of iframe calls had happened; i.e. that attesation.id is called first and it then calls devcon.org, then attesation.id could steal a user's ticket. Furthermore, attestation.id would need to be aware of all possible use-case sites (not just Devcon) and to know how to take contact to the correct one.

However, we do note that if devcon.org turns malicious it could request the secret for user's for which it just issued fake tickets. In this case it could be able to learn information allowing it to brute-force the email of arbitrary users who have an email Attestation from Attestation.id.

3

To be a bit more specific, the attack is only possible is Devcon is malicious and Devcon has not been revoked from the approve-list at attestation.id and a user visits a malicious third party site and the user has an attestation.id attestation and the user does not have a Devcon ticket. In this case Devcon can try to brute-force the user's email address locally.