Attestation secret is shared with DevCon

[jot2re]

See section 2.1.1 in the Token-negotiator report.
We note that while not pointed out in the Token-negotiator report, we believe that the problem can be fixed having attestation.id produce a special zero-knowledge proof, which can be validated by DevCon and combined with a zero-knowledge proof the ticket secret by DevCon. The combined zero-knowledge proof can then be verified by Hotel Bogota.

See this Jira issue.

[jot2re]

Yes, issues is that DevCon front end learns both attestation secret and ticket secret. This is not a huge issue. It is an issue we previously accepted as being needed a needed evil with our design. However I realised there is a way to prevent it.
This issue is about implementing the fix, if @weiwu-zhang thinks it is worth putting in the effort to handle.
(The expected time is not much, but the change must be done both in front end and back end)

[jot2re]

The issue is that if DevCon front learns the attestation secret, which means it could use the attestation in other settings (if they exist).
My thought about this suggestion was that the ZKP would be linked to a specific context such that the partial ZKP DevCon front received from the Attestation iframe cannot be used in other settings than the current proof. Hence protecting against misuse by a malicious DevCon front.

[jot2re]

@oleggrib

1. Yes, I think that would be great as a minimal fix.
2. Yes, that makes sense too. Although I think that making that work might be more complex than adapting the ZKP procedure as suggested should also handle this.

I think we should have a talk with Sunil or Weiwu about prioritising this issue and related issues of UN's and context in the ZKPs.