Protocol-Independent Cross-Origin Discovery Flow #2
Conversation
| - 1st party Cookie | ||
| - 3rd party cookies | ||
| - Redirect with link decoration | ||
| - Persistent Local Storage | ||
| - cross-domain postMessage |
There was a problem hiding this comment.
Would it be possible to highlight in the 'Description of flow' section how each of these are used? The use of local storage is already well described. I think it would be helpful for the scenario to highlight how 3rd party cookies are required as well as cross-domain postMessage.
There was a problem hiding this comment.
I think I went overboard with the pieces that are required for this specific use case. I've updated the file and updated the drawings to try and be more clear about exactly what/where the different components interact with browser features.
Updated required features, updated link to diagram
removing any protocol dependencies; added a better sequence diagram link to the description of the flow
hlflanagan
changed the title
| ### Description Of The Flow | ||
| A full design of the data flows used to support a central discovery service are available here: <https://docs.google.com/presentation/d/1h3XQ6BtTQ7KJkBQkIkWjktp3RXqHDXEKsa5ymrjzA-k/edit#slide=id.p> | ||
|
|
||
| This flow writes to browser local storage via a dedicated component which loads a non-displayed iFrame. |
There was a problem hiding this comment.
It would be great if there could be a bit more detail around how the iframe interacts with the local storage and where the iframe is embedded.
Less important: I'd prefer the seq diag to be included (I just added one to my scenario using the Online Server of https://plantuml.com/).
Attempting to capture the multilateral federation use case, specifically around WAYF services.