update design to avoid accessing 3rd party storage

[nicktaras]

When a user visits the ticket issuer website, the tickets will not load by default via Safari IOS. The user must navigate to their settings and remove the prevention of cross site cookies.

https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API/Using https://webkit.org/blog/8124/introducing-storage-access-api/

This ticket is to confirm if this is an acceptable experience for our end users.

If Yes. We can add details of how to change the settings. If No, we can look to apply a solution such as using Post Message, Storage Access API Flow for Safari.

Google to phase out third party cookies 2022 - https://www.theverge.com/2020/1/14/21064698/google-third-party-cookies-chrome-two-years-privacy-safari-firefox

[AW-STJ]

If Google is going to phase out 3rd party cookies before Devcon happens, then we will need to address it now.

Let us take a look at the alternative solution.

@colourful-land - can you give us some guidance. From chat with Nick, it seems like the full-proof solution would be to use a backend API / Service. However, this is how web 2.0 works.

[SmartLayer]

@nicktaras no not acceptable. but I don't remember we ever planed to access any 3rd party cookie or 3rd party website's local storage at all. @oleggrib said earlier all comms are done by messaging to/from iframe. If you are facing this problem, either @oleggrib 's work is not extensive enough to cover the negotiator case, or you are missing some of his code.

[SmartLayer]

@nicktaras I think this will work: when a user access issuer's website, the website opens an iframe to the issuer's outlet to get ticket information, just like the 3rd party website. It is the code in that outlet that decides to pass ticket token objects based in predefined whitelist rules in JAVASCRIPT, not that the issuer's website fetches data from local storage. Push, not fetch.

[nicktaras]

This is to share the current state - latest code. To help us to address the changes required.

[nicktaras]

Added notes from today's meeting:

• Nick to, work on a POC / solution to allow the current Iframe flow to work in Safari Browser
• The current solution to expose the ticket + secret inside the client (ticket outlet) needs to be further reviewed / solution presented to hide such data (e.g. solution such as Tornado - but probably something simpler, to hash the ticket data?)
• Oleh is working on a solution for Attestation.id with Feng (solution for after first deliverable to devcon is most likely)
• Nick to finalise the Yes/No check for Negotiator (in progress inside a different issue)

[SmartLayer]

@nicktaras the outlet should produce proof, not the secret used to make such proof. @oleggrib has code to produce such proof, just make sure it's produced in the outlet and sent out, not produced outside of the outlet by reading its secret.

[nicktaras]

@oleggrib could you share where the code you have produced for the proof can be located and I will integrate this.

[oleggrib]

https://github.com/TokenScript/attestation/blob/javascript-crypto/src/main/javascript/negotiator/src/Negotiator.js this is last source of Negotiator, it can interact between iframes

[nicktaras]

Re-opened this issue for the time being which contains resources to this issue / previous efforts made.

[nicktaras]

https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API

@colourful-land I'm going look at implementing this today - where if this works, this will enable our solution with Iframes to work across all major platforms.

Safari (Mobile and desktop), Firefox, Windows, Chrome, Android. Although experimental, I think this is the best route to take if this covers all the browsers.

Note:

• This WebKit feature is in an experimental stage
• UX - a gesture is required to enable cross site scripting e.g. a button click by the end user.

[nicktaras]

Closing this ticket, where we are no longer using cross origin communication with window.postmessage()

Additional notes:

Storage API only provided access to cookies, not local storage when a user gesture was made. This is also an experimental technology, where it has been avoided for now.

It is possible to use cross origin local storage, on the basis that the user has seen the origin tab - however if we think of an example where the user has 3 or more tokens across different issuer pages, this will be a very bad user experience.

The found solution is to use cross origin cookies, with the concept around attestation via the top window (embedded web components e.g. overlay + attestation.id modal).