Move Active negotiation selector to the Outlet iframe/tab

[oleggrib]

Currently user decide what token to use in the own page, where user have access to everyhting and webster can easy collect use tokens data by set mode to "passive" and track user for ads etc.
its not secure.

I suggest to move active negotiation token selector to the Outlet page.
In this case user always have to approve tokens to share, so webster cant silently track tokens where active negotiation set for Outlet.

It adds some challenge , because some browsers can force to show full size tabs, but Outlet page styles are separated from webster page and will look exact as we design it, no way to style overlap.

@nicktaras , @micwallace , @weiwu-zhang , what do you think?

[micwallace]

Agreed. I did a basic proof of concept for how this might work: http://tnwebster.tk/
Let me know if you want me to link the repo so you can play around with some ideas.

Do you reckon we need token-level approval? For instance if the Outlet hosts tickets for multiple events or vendors? This isn't possible with the current TN outlet code, but I can see how it could be useful.

[oleggrib]

@micwallace , correct, this is what I mean.

also Outlet page can display switch/radio and allow user to select specific tokens to share (similar to the current token selector popup)

about option to read multiple tokens: no problem to open iframes with multiple Outlets. no need to make things more complicated. we can open Token1 Client with iframe to some.domain.com/token1.html(Token1 Outlet embedded) and Token2 Client with iframe to some.domain.com/token2.html(Token2 Outlet embedded)
In this case we have to add token name as param for all postMessages to avoid postMessages collisions between different tokens.

[nicktaras]

Let’s look into a solution to address this Oleh, Miccy. I Agree, really good points made. Here are thoughts based the issue and ideas shared. At this time in our current solution: - token meta is not learnt by the website until they connect to an off chain issuer for active. - For passive as you mentioned Oleh, tokens are learnt without user permission given. Here are ideas towards a solution: - One idea is that we restrict passive negotiation to issuer websites. This would reduce complexity for general consumers of the token negotiator. It may have some restrictions depending on future use case needs. - Building upon your suggestion Oleh, by moving the overlay to an issuers outlet won’t work when there are multiple off chain tokens. I think this is an issue to restrict scalability of using more than one off chain token. However we could make an adjustment adding another Iframe like this: Client > Main Iframe > Outlet A (attestations) Outlet B (attestations) Outlet C (attestations) (Main Iframe would contain the overlay - and Outlet A, B, C would only contain the attestations, with logic to store, decode and dispatch token data)

[oleggrib]

@micwallace @nicktaras
is any page can request and receive all user tokens though hidden iframe?

I can see in examples that popup dont use iframe, but receive all tokens and request to select token on hotelBogota page. Right?

[nicktaras]

Hi @oleggrib, @micwallace,

Do we see any changes required to the management of attestations via this issue? This based on our current roadmap with regards to off chain technology.