On Tue, Oct 19, 2021 at 9:41 PM Sasha Tokarev <alex...@microsoft.com> wrote:
> *> All of this relates to the questions I was previously asking, because > at least if my understanding is correct, this basically means that as > currently designed, it's not possible to really describe a "standard" flow > or specification. For example, it's not that a particular cookie value will > be present, or a particular header value - the web account provider can > return arbitrary cookies via the > WebAccountProviderRetrieveCookiesOperation, and these should just be passed > on to any of the managedUrls. So IdP Foo might call their cookie "SID", > while IdP Bar might call their cookie "Token", and IdP Baz might use > multiple cookies, like "CAW", "DIDC", and "DIDCL". The browser should just > overwrite any cookies it has (e.g. from the browser cookie jar, or from > extensions) with the cookies provided by the Web Account > Provider/IProofOfPossessionCookieInfoManager - right?* > > > > -True, we tried to make IDP life easier, we wanted them to use any cookies > names and semantic. Cookies are a private contract between IDP native > component and IDP web service. We never pursued the goal to standardize > this aspect. > > > > All we can spec for browser SSO on Windows: > > 1. Windows can have a native IDP component, which installed by the > user or built-in in the platform. > 2. There is a public API that any web browser can use to pull a list > of cookies/headers when navigation happens to an IDP url. > 3. Cookie/header names and their semantic is a private contract > between an IDP web and its native component on the platform. > 4. The web browser should just override cookies with the same names. > > > > I hope it clarifies. > It really does, and helps understand how this is a very new, very different integration, and does affect some of the understanding of how this fits in the overall Web Platform and interop story (while being mindful of balancing that with our existing threat model) <https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/security/faq.md#Why-arent-physically_local-attacks-in-Chromes-threat-model> . One question I had, that I forgot to follow-up on: with these APIs; whether WebAccountProviderRetrieveCookiesOperation or IProofOfPossessionCookieInfoManager::GetCookieInfoForUri, these deal with cookies. You mentioned headers a few times - could you provide any pointers to where the header interactions are / what the APIs? The context here that I'm thinking about is situations like cookie size limits and how these PoP cookies, which we don't know the size apriori, would interact with the browser cookie store. The use of headers mitigates some of that, although with their own complexities, and so it'd be useful to understand what that API shape looks like. > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACvaWvZ9kycd2o9YXUQebQM5pEppUnFTkEwefmQLjCiJOmCg5w%40mail.gmail.com.
