Hi Ryan, Thank you for your email.
One logistics aspect: I don’t know the culture in this DL is it ok to merge 2 different forks in one or keep forks independent. I decided to keep fork independent as they were not created by me, but expect @Owen<mailto:[email protected]> or somebody help me with this. > Is there a public specification for this flow? Yes and no 😊 overall there are a lot of protocols that controls relationships between IDP and web-application (aka resource, aka target-resource, aka application). These protocols are public and are not subject to this proposal. In all those protocols when request reaches to IDP, job of IDP to authenticate the user. As I said in a different thread the IDP, including Google, will store a cookie to prevent re-auth. In scope of this proposal is how IDP will pull a cookie from a native component. It is a relationship between IDP and IDP’s native component that is part of operation system. On Windows we have a framework WebAccountManager<https://docs.microsoft.com/en-us/uwp/api/windows.security.authentication.web.provider?view=winrt-20348> (WAM) that allow Google to add their own authentication plugin. If Google ever decide to do it, then users will be able to read email from Outlook or modify Google docs in Word. We wish Google to add this plugin, and we can help with it. Here is how the WAM plugin relates to browser SSO. Assume Google creates the plugin. 1. User opens Word, and enters his/her Gmail account to access Google Drive, in Google WAM plugin (relationship between User and Google) 2. Google WAM Plugin asks “Do you want add this account to Windows and able to access Google services from everywhere other applications and web?” 3. User clicks yes. 4. Google WAM plugin creates SSO artifact, and creates account in the system, user can control it from Settings. 5. User launches Outlook and Outlooks and can read Gmail from Outlook. 6. User opens a web browser Edge, IE, FireFox, Chrome navigates to gmail.com. * Gmail.com navigates to accounts.google.com * Web browser sees that accounts.google.com in a registered Url list. * Web browser calls api to pull the cookies GetCookieForUri<https://docs.microsoft.com/en-us/windows/win32/api/proofofpossessioncookieinfo/nf-proofofpossessioncookieinfo-iproofofpossessioncookieinfomanager-getcookieinfoforuri>. * Web browser appends these cookies to the request to accounts.google.com * Account.google.com validates cookies and proof of possession authenticates the user and redirect back to Gmail.com with token. * Gmail.com displays user’s emails. Please, note, only 6.b-d is in scope of the current ask. I skipped a lot of details, but this is a high-level end to end flow, which describes it is not about Microsoft, it about relationship application and browser SSO. Unfortunately, Google decided not to implement Google WAM plugin (I don’t know why 😊), while the plugin could make Google services closer to Windows users. Only Microsoft (MSA and AAD) implemented their plugins. Why it is not a standard auth protocol? Because only few vendors in the world supposed to implement it Facebook, Google, Amazon, Microsoft, and only one implemented end to end. If Google want to participate from IDP side, we can discuss how to make and official protocol from this. > This seems a little more difficult when OS vendor != Browser vendor != > Identity Provider, I hope by this moment it is clear that this is relationship between Native IDP component that part of OS, and web part of IDP, and browser. Expectation is: vendor of native IDP component in OS == vendor of IDP in web != Browser vendor. There is no expectation that someone install a web server which will authenticate by pulling cookies, those cookies visible only to IDP web site, but we can discuss how to officially spec it. > Could you expand on this "header or cookie"? By default, we treat it as cookie. It should behave like cookie. Logic is following, if there is no WAM plugin, account.google.com will store a cookie. “cookie” that we return from that API is more secure than regular cookie, as it is TPM bound. Basically, when you call that API you pull a short lived, tpm bound, sso-cookie - it is more stronger than regular cookie. We switched to headers, because when we have multiple accounts on the system, we hit cookie size limit and proxy blocks requests, or removes cookies. However, by nature it is a cookies, and all cookies rules must apply, for example browser MUST NOT append this header to a different URL to avoid security incidents. > I can imagine issues if we persisted those cookies to disk It is ok to persist them on the disk. You store regular cookies from IDP on the disk. This stuff more secure. They protected from stealing. It is IDP native component responsibility to take care of this. > That is, in the worst case, it seems like a vulnerability in the IDP provider > can make the browsing experience unsafe, and the responsibility for that > failure will be shared (i.e. users will blame the browser for exposing the > feature, and the IDP for failing to secure it appropriately). It is a case right now. As I’ve said earlier IDPs already store cookies and “a vulnerability in the IDP provider can make the browsing experience unsafe”. This proposal doesn’t change anything in this aspect. Only adds new place for storing/reading cookie, the native component of IDP, and make cookie more secure. > Do you have any thoughts on how the browser can help make sure that the IdP > is acting in the best interests of the user? This is a more generic question, that we can discuss, but as I’ve said earlier with this proposal, we don’t change anything in this aspect. Hence, we will just diverge the conversation. I think it is better to discuss this topic with OIDC or OAuth group. > It sounds like the assumption here is that the user will explicitly accept > this risk when they configure the OS for the IdP, is that right? Yes > In that model, how can the browser be sure the user made an informed choice, > and affirmatively wants the browser to behave this way? How today, the browser is sure that the user made an informative choice by authenticating in accounts.gmail.com and consented to persist the cookie? > Is the scenario here that the browser should just trust the OS, or is a model > where the browser also confirms with the user (e.g. via enterprise policy or > user consent) part of the thinking? Browser should just trust OS, the same as it trusts when it calls ReadFile windows API to read cookie file. How a browser sure that we Microsoft underneath on driver level read right bits, and not feed cookie from WAM plugin? I think OS and browser share responsibility to do right thing. We, OS, cannot insert a hook in read file api to give some data that will be useful for us, because when people will discover it, and it will be discovered, we will be in very bad situation. Overall, from my understanding of the software development, the browser has no option “Do not trust OS” OS can do everything in the browser memory space. We should trust each other 😊. The same statement applies to IDPs, browser should trust IDPs, if an IDP makes a mistake or misbehaves users will punish them by dollar. * * Validates if the resource owner (enterprise admin or user) authorizes access to the resource. * Applies consent policy and ask consent if needed, for example enterprises, when they own the resource can pre-consent access by their employees. Note, It is responsibility of IDP to ensure that only authorized and consented applications can access users’ identity. I'm not sure I fully understand this part. Could you share more? Specifically, it's unclear if "applications" here are referring to OS level applications (like the browser), or to web applications (like a relying party). “application” here is “web-applications” (==resource). This part about consent. Overall, consent is a big topic, and usually consent starts from who owns the resources. If it is a document on my personal OneDrive or Google drive, then I’m the owner. If it is on my corporate OneDrive or SharePoint, then my company is the owner. The owner decides who can access, and which application can access. Also, in the enterprise world the consent story even more complex, employees should not use some random applications without pre-authorization from management. All those relationships managed by IDP and I don’t see how browser can help here, as the browser doesn’t know who the owner is, what was pre-authorized for accessing without consent, what was forbidden, etc. The browser can only destruct by very questionable prompts. > Earlier, you mentioned "header or cookie", and this seems to be describing > "SSO headers and cookies". I wasn't sure if it was either/or or both - could > you clarify? In some case we issue cookies, in some cases header, but both header and cookies should behave like cookie. It is only question of size limitation on cookies. > Just making sure I parse this: the "user consent" being described is from the > IdP, right? So the IdP learns about the user's activity - whether malicious > or benign websites - and is responsible for helping the user distinguish > between those two? Right, IDP must not allow a malicious web site to access data without authorization. > And is it correct that when you say “enterprise account”, this is in > reference to the IdP’s notion, not the OS/browser notion? Here it is user account in IDP notion. IDP can serve enterprise needs, and personal/consumer accounts needs. Azure Active Directory is IDP for enterprises (aka organizational accounts, aka work or school accounts) it is Azure AD responsibility to know who can access what, and Azure AD has huge portal which allows amdin to control its resources. While Google Account, or Microsoft Account, or Facebook is usually mange consumers identity. In one logon session in OS, you can have multiple enterprise accounts and multiple personal/consumers accounts. Additionally, you can be logged in using your personal account via operation system logon, or using your enterprise account. So, “enterprise account” can be applied to windows logon as well. However, in that context, I meant “if there was enterprise account delivered via cookie then consent logic is not sufficient we need to take into consideration if admin allowed this relationship and other enterprise policies”. > This is where having a clearer protocol specification will be useful. Once you read everything, and digest, could you, please, advice what part do you want to spec? I see that we can formally document only this: 1. Browser reads list of urls from OS 2. If navigation happens for an interesting URL, then browser should call API to get cookies or headers. 3. Browser appends cookies or headers to the request. 4. If it is header it should appended in all places where cookies are appended, on any navigation to an interesting URL. Is that what matches your expectation we should spec? > if there are protocol concerns (e.g. the headers vs cookies discussion), does > the fact that it sounds like the IdP and the OS are both same-party mean that > there may be a possibility of adjusting the protocol to better fit with the > Web Platform? I’m fine to jump and building new protocol, but by the time we adjust OS and release new protocol, Chrome users will be impacted, as they will be blocked by device conditional access. Right now, Chrome user experience degraded experience compared to Edge and Firefox, in some cases they even blocked. Release a new protocol will take us a year or more, and most likely will be in a new version of Windows (+ 2 years when majority population will be on that version). Thank you, Aleksandr From: Ryan Sleevi <[email protected]> Sent: Saturday, September 25, 2021 11:17 AM To: Owen Min <[email protected]> Cc: blink-dev <[email protected]>; Sasha Tokarev <[email protected]>; Greg Thompson <[email protected]>; Matt Menke <[email protected]>; Ryan Sleevi <[email protected]>; Adam Langley <[email protected]>; Yutaka Hirano <[email protected]> Subject: [EXTERNAL] Re: Native support of Windows SSO in Chrome Thanks for the heads up Owen, and thanks Aleksandr for starting the discussion! I have a lot of questions below, so hopefully it's not overwhelming. This is certainly a very interesting space, and a great chance to modernize things, but also seems like it poses some unique risks. On Thu, Sep 23, 2021 at 5:18 PM Owen Min <[email protected]<mailto:[email protected]>> wrote: +people who may be interested in this. On Thursday, September 23, 2021 at 12:21:51 PM UTC-4 Sasha Tokarev wrote: Hi all, I have a proposal to integration with Windows SSO in Chrome. Currently Windows has ability to join device to cloud identity, like AAD, MSA. When a device is joined to a cloud identity provider (IDP), it would be great if I’m as a user do not need enter credentials, when I’m using a service, which uses IDP where my device is joined to. I’m consented to have single sign on (SSO) when I joined the device, and trust IDP to protect my identity and do not allow an authorized access. If I do not trust, I should not join my device. Additionally, sometimes web resources, that I’m accessing to as a user, are owned by organization where I work or study. Hence, an organization administrator should be able to manage access to such resources based on the quality of my device, e.g., prevent access if the device doesn’t make malware scans or doesn’t have latest security patches etc. Edge has this feature built in, in Chrome we must use a special extension https://chrome.google.com/webstore/detail/windows-10-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchrome.google.com%2Fwebstore%2Fdetail%2Fwindows-10-accounts%2Fppnbnpeolgkicgegkbkbjmhlideopiji&data=04%7C01%7Calextok%40microsoft.com%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597816979%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EPWwy814QsxgN9I%2FqXA3owMHcl%2FP%2BTQMWiWTAtrm9cQ%3D&reserved=0> While using extension works, the built-in experience is better, as we have with Windows Integrated authentication. In high level it should work like this, if I’m accessing to a resource, from a joined device. Is there a public specification for this flow? For example, with existing OS SSO integration, we have a standard set of APIs (GSS-API on Posix platforms, SSPI on Windows, which are both conceptually similar), and a set of specifications for how they interact with Web technologies. I ask, because Negotiate/Kerberos/NTLM integration is already<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.w3.org%2FArchives%2FPublic%2Fietf-http-wg%2F2012AprJun%2F0690.html&data=04%7C01%7Calextok%40microsoft.com%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597826974%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wQ0dtnzzRXcFgjLbne%2Bqz%2F70x3grYDD5DLw4rLyf%2Fv8%3D&reserved=0> a bit of an outlier<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7235%23section-5.1.2&data=04%7C01%7Calextok%40microsoft.com%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597836979%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AY286MUj4hCo%2FmGVDuc4PC2j86rQ%2FqnBjPIQB2OAHGg%3D&reserved=0>, in that it didn't follow the WWW-Authenticate or HTTP semantics. This makes it challenging to support in new protocols (e.g. HTTP/2 or HTTP/3). It seems like, as part of this, having a sense for the specification would be very helpful here. 1. Resource (e.g., www.mywork.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mywork.com%2F&data=04%7C01%7Calextok%40microsoft.com%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597836979%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WJWyylDqFui8UaNcrKOuDhKdNeIb01hUsx1Ia0Q6LkU%3D&reserved=0>) will redirect me for the authentication to the cloud identity provider(https://login.microsoftonline.com<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flogin.microsoftonline.com%2F&data=04%7C01%7Calextok%40microsoft.com%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597846970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5kzfSLO8COAFQfvOte9mEN1%2FyLclYdiuiuD%2Fa00kPHQ%3D&reserved=0>). The request will have a redirect URI that IDP will use to return a token. 2. User agent (Chrome) will detect this navigation and call an OS API for producing a crypto-protected SSO cookies, which has device and user information. This cookie will be appended to the request as a header or cookie. Could you expand on this "header or cookie"? That is, appending cookies from the OS introduces a whole host of complexity considerations, and has to be reasoned about through the network stack. For example, I can imagine issues if we persisted those cookies to disk, since it sounds like the intent is that the cookie value is actually some ephemeral nonce-like/time-bounded thing. This gets messy when merging, and of course, from a privacy angle, when clearing. Having a bit of semantic separation at the transport layer, like a header, seems useful. This is the first I've heard in the context of this feature that a header is viable, and would love to understand and explore that more, because it might address a number of the concerns/considerations. 1. 2. Cloud identity provider ( https://login.microsoftonline.com<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flogin.microsoftonline.com%2F&data=04%7C01%7Calextok%40microsoft.com%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597846970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5kzfSLO8COAFQfvOte9mEN1%2FyLclYdiuiuD%2Fa00kPHQ%3D&reserved=0> ): * Detects presence of the SSO cookies, validates them by checking signature, and authenticates the user and device. * Validates that the supplied redirect uri is registered for this application. >From a threat model standpoint, this makes a lot of sense when OS vendor == >Browser vendor == Identity Provider. If you don't trust them, really the whole >system collapses. This seems a little more difficult when OS vendor != Browser vendor != Identity Provider, because the responsibilities for privacy and security get divvied up among multiple stakeholders. That is, in the worst case, it seems like a vulnerability in the IDP provider can make the browsing experience unsafe, and the responsibility for that failure will be shared (i.e. users will blame the browser for exposing the feature, and the IDP for failing to secure it appropriately). Do you have any thoughts on how the browser can help make sure that the IdP is acting in the best interests of the user? It sounds like the assumption here is that the user will explicitly accept this risk when they configure the OS for the IdP, is that right? In that model, how can the browser be sure the user made an informed choice, and affirmatively wants the browser to behave this way? Is the scenario here that the browser should just trust the OS, or is a model where the browser also confirms with the user (e.g. via enterprise policy or user consent) part of the thinking? * * Validates if the resource owner (enterprise admin or user) authorizes access to the resource. * Applies consent policy and ask consent if needed, for example enterprises, when they own the resource can pre-consent access by their employees. Note, It is responsibility of IDP to ensure that only authorized and consented applications can access users’ identity. I'm not sure I fully understand this part. Could you share more? Specifically, it's unclear if "applications" here are referring to OS level applications (like the browser), or to web applications (like a relying party). * * Read device identity, and checks the state of device, that reported out of band by device management system. * If all checks are fine, the IDP redirect back to the resource with a token. 1. User agent (Chrome) should not do much, just to make sure it will not include SSO headers (as in case of some HTTP Redirects user-agent repeats the same headers) and cookies to the resource, to prevent its disclosure. Earlier, you mentioned "header or cookie", and this seems to be describing "SSO headers and cookies". I wasn't sure if it was either/or or both - could you clarify? 1. 2. Resource gets the token and provides service to the user. Note, a malicious web site will not be able to access user identity without explicit user consent, and if it is an enterprise account, then it should check admin authorization for this application. Just making sure I parse this: the "user consent" being described is from the IdP, right? So the IdP learns about the user's activity - whether malicious or benign websites - and is responsible for helping the user distinguish between those two? And is it correct that when you say "enterprise account", this is in reference to the IdP's notion, not the OS/browser notion? One may think that if we have SSO, now we need to think about protection from malicious web sites. However, this issue is not relevant to SSO, as if a user has either MSA or AAD, most likely she or he will enter credentials at some moment, and IDP will store persistent cookie. As a result, IDP still needs to protect from a malicious web site, that is why all protocols that use redirection has special handling for such cases, i.e. the IDP must redirect on initially pre-registered for this client redirect URI https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc6749%23section-3.1.2&data=04%7C01%7Calextok%40microsoft.com%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597856953%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TYkKFJeNBwE1JCncmKJ36M2KjSB73K0DkWtPBzt%2BUpo%3D&reserved=0> This is where having a clearer protocol specification will be useful. For example, the OpenID Foundation is working on making it easier for RPs and IdPs to establish relationships, through the FastFed Working Group<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fwg%2Ffastfed%2F&data=04%7C01%7Calextok%40microsoft.com%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597856953%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bs%2F6oIObhSvihiKJBDvmSpgaXU%2FeioazzKOT2JgZLXs%3D&reserved=0>. I recently shared some concerns<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fpipermail%2Fopenid-specs-fastfed%2FWeek-of-Mon-20210823%2F000358.html&data=04%7C01%7Calextok%40microsoft.com%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597866965%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FN%2F%2BkVCqCpAnA%2BLmeDCwmqFrFxMwQb4dKvfrybOCLMw%3D&reserved=0> with some of the current draft's assumptions, and how they might facilitate malicious RPs or impersonating IdPs. It'd be useful to have a broader sense of the protocol at play here, since it sounds like the core goal is for the browser to trust the IdP, on the basis that the OS is configured to trust the IdP, and that both the user intentionally configured the OS, and that the user explicitly confirmed with the IdP. I'm not trying to suggest anything nefarious here, but trying to make sure we've got a good understanding of the assumptions we make. These may be entirely reasonable assumptions (e.g. the OS threat model is explicitly addressed as out of scope<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%2F%2B%2Frefs%2Fheads%2Fmain%2Fdocs%2Fsecurity%2Ffaq.md%23Why-arent-physically_local-attacks-in-Chromes-threat-model&data=04%7C01%7Calextok%40microsoft.com%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597866965%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QZ1HDw%2FUnVFQZC8ya%2FPtvx8drQNLfSYGJQJTv87%2FSOM%3D&reserved=0> in the security FAQ), but it may also reveal complicated interactions that could limit the evolution of new protocols (e.g. as Negotiate/Kerberos/NTLM did re: HTTP/2 and HTTP/3) or present challenges to some of the work regarding privacy sandbox<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.chromium.org%2FHome%2Fchromium-privacy%2Fprivacy-sandbox&data=04%7C01%7Calextok%40microsoft.com%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597876943%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZU5f9CA2zdgBXZeJTX%2FSQRHifQTZ2rbWSt7AlCkpC0o%3D&reserved=0>. The more documentation you can provide about the protocol interactions, the easier it is to evaluate those and be confident the risks are mitigated. SSO itself reduces number of prompts, OS cookies are hardware crypto protected and short-lived, while protection of web-cookies is lower. Integration with OS SSO not just a convenience feature but increases users’ security. Absolutely, there's a lot of good stuff that can be done. Ideally, however, we can pursue that through standards, such as WebAuthN, to help ensure users are secure regardless of the OS or IdP. Obviously, we still support protocols like Kerberos and NTLM, so it's not that OS integration doesn't make any sense - just that it comes with its own set of risks and tradeoffs. One way of thinking about this is that bringing in some of these high-level protocols from the OS - from any OS - is a bit like adding third-party libraries<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc.git%2F%2B%2FHEAD%2Fdocs%2Fadding_to_third_party.md&data=04%7C01%7Calextok%40microsoft.com%7C22e6d81e38e8460461e208d98050bed0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681906597876943%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mn5%2BXAksutP2iOoMDy6ByuJ592Oav4GiVktfFKvonfo%3D&reserved=0>, since it extends the attack surface of the browser. We obviously add 3P libraries all the time, so it's not that I'm saying we shouldn't do this at all, but it's good to get a sense of how it will work, both technically and with web standards, to evaluate the risk. One last question, if I haven't overwhelmed you with questions already - if there are protocol concerns (e.g. the headers vs cookies discussion), does the fact that it sounds like the IdP and the OS are both same-party mean that there may be a possibility of adjusting the protocol to better fit with the Web Platform? I realize that's probably a huge request, and it may be the answer is "No, none of this can change" - but I'm asking now, mostly to understand "What do we do if the new protocol has similar spec-violating issues like Negotiate/Kerberos/NTLM did", and what the options might be to prevent or address that. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SN6PR00MB0381F695F6689DB38BAC1BEAA1A69%40SN6PR00MB0381.namprd00.prod.outlook.com.
