Thanks for the super-detailed response Aleksander! To reflect what Matt said, don't feel the need to respond on vacation :)
Regarding the forks: I suspect this might be how GMail vs Outlook differ in managing threads, since in Google Groups and GMails, it appears as all one conversation <https://groups.google.com/a/chromium.org/g/blink-dev/c/zJpLAAz4RtE/m/gZ9RwDqmBAAJ>, not as forks. You shouldn't have to worry too much about it :) This was a super-helpful response, and I think it teases out a few things worth digging into further. >From your remark about WAM, it seems like this is a generic extensibility framework <https://channel9.msdn.com/Events/Build/2015/2-709>, for any IDP - from Microsoft, Google, Okta, etc - to be able to hook the not only the browser's network stack (effectively), but any consenting applications' network stacks, and be able to inject arbitrary cookie names and values <https://docs.microsoft.com/en-us/uwp/api/windows.security.authentication.web.provider.webaccountproviderretrievecookiesoperation?view=winrt-20348>. It appears these providers may be device-wide (although only Microsoft IdPs <https://docs.microsoft.com/en-us/uwp/api/windows.security.credentials.webaccountprovider.issystemprovider?view=winrt-20348#Windows_Security_Credentials_WebAccountProvider_IsSystemProvider> are supported for that), but are primarily user-wide. If I'm understanding correctly, any IdP application can register to be the handler <https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-uap-webaccountprovider> for a given IdP URL. It seems, from my limited understanding, to be a bit like an OS extension, rather than a browser extension - and to allow third-party software to affect the authentication flow, not only within a browser, but within all apps (that opt-in to supporting this). Although Windows already had an extensible API for adding authentication providers - SSPI and the Negotiate method - it has the downsides I mentioned in my previous e-mail, of being incompatible with modern transport technologies, as well as being a hugely complex thing to implement client and server (CredMan <https://docs.microsoft.com/en-us/windows/win32/secauthn/winlogon-and-credential-providers> is easier than GINA <https://docs.microsoft.com/en-us/windows/win32/secauthn/winlogon-and-gina>, but not by much, and SSP/APs <https://docs.microsoft.com/en-us/windows/win32/secauthn/creating-custom-security-packages> aren't fun to write, and it seems like this is the next evolution in this space, ignoring ADAL/MSAL <https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-overview> :D). I'm just trying to make sure I understand the space of where this fits, on the Windows side of things, since that helps inform a bit how we've evaluated security/privacy risks in the past. Architecturally, as it relates to Chrome/Chromium, this seems a little like offering an OS-provided pluggable OAuth2 Access Token Manager <https://source.chromium.org/chromium/chromium/src/+/main:google_apis/gaia/;drc=58df57696ad9b3eb757ebb80c9dfe8318d4b0674>, except further, not bounded to having to use OAuth2. Conceptually, a browser wide notion of the current user's identity, which can be provided to websites as needed. Unlike the current implementation, rather than triggered by signing in to the browser, it's provided by the OS's extensibility framework and signing into the OS itself. Is that at least conceptually right? That is, if you sign in to Chrome today, and then a web resource wants to go through Google's IdP, Chrome is able to make the user's logged in state available to the IdP, creating a frictionless flow between the browser content and the Web content, similar (though not identical) to the Desktop Identity Consistency effort - where signing in to the IdP in the Web allows you to sign in to Chrome (the app). Assuming I haven't bungled things too much yet, a specific question is whether WAM is what serves as the backing implementation for IProofOfPossessionCookieInfoManager::GetCookieInfoForUri <https://docs.microsoft.com/en-us/windows/win32/api/proofofpossessioncookieinfo/nn-proofofpossessioncookieinfo-iproofofpossessioncookieinfomanager>. The WAM remarks are all .NET managed code, and it sounds like this COM interface provides a handy abstraction around that logic. For example, for a given URI, it would see if it matches one of the web account provider's managedUrls, and if so, call RetrieveCookies on the web account provider, and then make those available via cookieInfoCount/cookieInfo. If no provider was registered, I imagine it'd just return no cookies. I have no idea if this is remotely correct, and if I've completely bungled it, I was hoping you could explain the relationship between WAM and IProofOfPossessionCookieInfoManager :) I also wasn't sure if the proposal here was that Chrome should be calling WAM directly (via a Managed DLL), or if using COM is the recommended approach. 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? Before I ask more follow-up questions about the browser-side implementation, I figure this is probably a good checkpoint to make sure I haven't completely bungled everything. On Sun, Sep 26, 2021 at 3:25 AM Sasha Tokarev <alex...@microsoft.com> wrote: > 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 > <z...@chromium.org> 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. > 1. *Gmail.com* navigates to accounts.google.com > 2. *Web browser* sees that accounts.google.com in a registered Url > list. > 3. *Web browser* calls api to pull the cookies GetCookieForUri > > <https://docs.microsoft.com/en-us/windows/win32/api/proofofpossessioncookieinfo/nf-proofofpossessioncookieinfo-iproofofpossessioncookieinfomanager-getcookieinfoforuri> > . > 4. *Web browser* appends these cookies to the request to > accounts.google.com > 5. *Account.google.com <http://Account.google.com>* validates > cookies and proof of possession authenticates the user and redirect > back to > Gmail.com with token. > 6. *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. > > > > > > 1. > 2. *Validates if the resource owner (enterprise admin or user) > authorizes access to the resource.* > 3. *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 <rsle...@chromium.org> > *Sent:* Saturday, September 25, 2021 11:17 AM > *To:* Owen Min <z...@chromium.org> > *Cc:* blink-dev <blink-dev@chromium.org>; Sasha Tokarev < > alex...@microsoft.com>; Greg Thompson <g...@chromium.org>; Matt Menke < > mme...@chromium.org>; Ryan Sleevi <rsle...@chromium.org>; Adam Langley < > a...@chromium.org>; Yutaka Hirano <yhir...@chromium.org> > *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 <z...@chromium.org> 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> > ): > > > 1. Detects presence of the SSO cookies, validates them by checking > signature, and authenticates the user and device. > 2. 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? > > > > > 1. > 2. Validates if the resource owner (enterprise admin or user) > authorizes access to the resource. > 3. 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). > > > > > 1. > 2. Read device identity, and checks the state of device, that > reported out of band by device management system. > 3. 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACvaWvYrLxCNth%2BTwPekKbQj-pXSKSm-Ck-Xw7MtwBLP0NykPg%40mail.gmail.com.
