Re: [blink-dev] RE: [EXTERNAL] Re: Native support of Windows SSO in Chrome

[Matt Menke]

On Fri, Oct 28, 2022 at 7:07 PM Sasha Tokarev  wrote:

> Hi John,
>
>
>
> Sorry for the delay.
>
>
>
> 1) Can we avoid modifying the Cookie header, and only modify "x-ms-"
> headers?
>
> - No, in some version of windows we use Cookie instead of headers.
>

I'm not seeing why this is an issue?  It's not difficult to check two
different request headers, server-side.  Cookies have web standard
behavior, which these don't obey, so it seems safer to use a separate
header, rather than provide APIs to manipulate Cookies within Chromium for
the sake of things that are not cookies.


> 2) Can this be scoped to just frame requests, e.g. only for requests to
> fetch the html for main frames and subframes and not subresource requests
> like images, XHR, JS, CSS etc. requests? Igor had tried this locally and it
> seemed to work.
>
>
>
> - some customers have a proxy, which redirects to all requests, including
> from images to their internal service, authenticates the user via AAD and
> redirects back if this request is authorized to the user. Can you do it for
> frame request only – yes, and it will cover most of the scenarios, but the
> previous one will not work in Chrome. My recommendation would be to do in
> all requests.
>
>
>
> Thank you,
>
> Sasha
>
>
>
> *From:* John Abd-El-Malek 
> *Sent:* Tuesday, October 18, 2022 12:58 PM
> *To:* Sasha Tokarev 
> *Cc:* Matt Menke ; blink-dev ;
> Owen Min ; Greg Thompson ; Ryan
> Sleevi ; Adam Langley 
> *Subject:* Re: [blink-dev] RE: [EXTERNAL] Re: Native support of Windows
> SSO in Chrome
>
>
>
> You don't often get email from j...@chromium.org. Learn why this is
> important <https://aka.ms/LearnAboutSenderIdentification>
>
> Hi Sasha, I got looped in to a code review and I had a few questions:
>
>
>
> 1) Can we avoid modifying the Cookie header, and only modify "x-ms-"
> headers?
>
> 2) Can this be scoped to just frame requests, e.g. only for requests to
> fetch the html for main frames and subframes and not subresource requests
> like images, XHR, JS, CSS etc. requests? Igor had tried this locally and it
> seemed to work.
>
>
>
> If we can do the above, either right away or with small changes to your
> server, we can simplify the implementation in Chrome. This in turn would
> help us reach a lower maintenance burden while still being performant.
>
>
>
> Thanks
>
>
>
> On Thu, Aug 11, 2022 at 4:30 PM 'Sasha Tokarev' via blink-dev <
> blink-dev@chromium.org> wrote:
>
> With respect to credential mode “omit” it is fine not send those headers,
> if the other mode will allow it.
>
>
>
> We use sandboxed iframes in out authentication libs, but we set
> “allow-same-origin” token to be able to use cookies.
>
>
>
>
> https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/6756b300c5696ad4890f1f7f27de69f6941a71e7/lib/msal-browser/src/interaction_handler/SilentHandler.ts#L143
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzureAD%2Fmicrosoft-authentication-library-for-js%2Fblob%2F6756b300c5696ad4890f1f7f27de69f6941a71e7%2Flib%2Fmsal-browser%2Fsrc%2Finteraction_handler%2FSilentHandler.ts%23L143&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716146352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=vS14Xw7x%2FQvSsDsyCFOzjXy22HfbHsTeP7qGnbfYYeM%3D&reserved=0>
>
>
>
> We fine if “allow-same-origin” will relax restriction of not sending
> cookies.
>
>
>
>
> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-sandbox
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FHTML%2FElement%2Fiframe%23attr-sandbox&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716146352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=dWrHKcXb7EVPimVkz%2FsUvbSEAYDhmstMlGKIPAj8ZvY%3D&reserved=0>
>
>
>
> Thank you,
>
> Sasha
>
>
>
> *From:* Matt Menke 
> *Sent:* Thursday, August 11, 2022 3:09 PM
> *To:* Sasha Tokarev 
> *Cc:* blink-dev ; Owen Min ;
> Greg Thompson ; Ryan Sleevi ;
> Adam Langley 
> *Subject:* Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome
>
>
>
>
>
>
>
> On Thu, Aug 11, 2022 at 5:43 PM Sasha Tokarev 
> wrote:
>
> Hi Matt,
>
>
>
> I apologize for not being able to respond, I was on va

RE: [blink-dev] RE: [EXTERNAL] Re: Native support of Windows SSO in Chrome

['Sasha Tokarev' via blink-dev]

Hi John,

Sorry for the delay.

1) Can we avoid modifying the Cookie header, and only modify "x-ms-" headers?
- No, in some version of windows we use Cookie instead of headers.

2) Can this be scoped to just frame requests, e.g. only for requests to fetch 
the html for main frames and subframes and not subresource requests like 
images, XHR, JS, CSS etc. requests? Igor had tried this locally and it seemed 
to work.

- some customers have a proxy, which redirects to all requests, including from 
images to their internal service, authenticates the user via AAD and redirects 
back if this request is authorized to the user. Can you do it for frame request 
only – yes, and it will cover most of the scenarios, but the previous one will 
not work in Chrome. My recommendation would be to do in all requests.

Thank you,
Sasha

From: John Abd-El-Malek 
Sent: Tuesday, October 18, 2022 12:58 PM
To: Sasha Tokarev 
Cc: Matt Menke ; blink-dev ; Owen 
Min ; Greg Thompson ; Ryan Sleevi 
; Adam Langley 
Subject: Re: [blink-dev] RE: [EXTERNAL] Re: Native support of Windows SSO in 
Chrome

You don't often get email from j...@chromium.org<mailto:j...@chromium.org>. 
Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Hi Sasha, I got looped in to a code review and I had a few questions:

1) Can we avoid modifying the Cookie header, and only modify "x-ms-" headers?
2) Can this be scoped to just frame requests, e.g. only for requests to fetch 
the html for main frames and subframes and not subresource requests like 
images, XHR, JS, CSS etc. requests? Igor had tried this locally and it seemed 
to work.

If we can do the above, either right away or with small changes to your server, 
we can simplify the implementation in Chrome. This in turn would help us reach 
a lower maintenance burden while still being performant.

Thanks

On Thu, Aug 11, 2022 at 4:30 PM 'Sasha Tokarev' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
With respect to credential mode “omit” it is fine not send those headers, if 
the other mode will allow it.

We use sandboxed iframes in out authentication libs, but we set 
“allow-same-origin” token to be able to use cookies.

https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/6756b300c5696ad4890f1f7f27de69f6941a71e7/lib/msal-browser/src/interaction_handler/SilentHandler.ts#L143<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzureAD%2Fmicrosoft-authentication-library-for-js%2Fblob%2F6756b300c5696ad4890f1f7f27de69f6941a71e7%2Flib%2Fmsal-browser%2Fsrc%2Finteraction_handler%2FSilentHandler.ts%23L143&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716146352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=vS14Xw7x%2FQvSsDsyCFOzjXy22HfbHsTeP7qGnbfYYeM%3D&reserved=0>

We fine if “allow-same-origin” will relax restriction of not sending cookies.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-sandbox<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FHTML%2FElement%2Fiframe%23attr-sandbox&data=05%7C01%7Calextok%40microsoft.com%7C4d6e3ce176274255269008dab14328fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638017200716146352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=dWrHKcXb7EVPimVkz%2FsUvbSEAYDhmstMlGKIPAj8ZvY%3D&reserved=0>

Thank you,
Sasha

From: Matt Menke mailto:mme...@chromium.org>>
Sent: Thursday, August 11, 2022 3:09 PM
To: Sasha Tokarev mailto:alex...@microsoft.com>>
Cc: blink-dev mailto:blink-dev@chromium.org>>; Owen Min 
mailto:z...@chromium.org>>; Greg Thompson 
mailto:g...@chromium.org>>; Ryan Sleevi 
mailto:rsle...@chromium.org>>; Adam Langley 
mailto:a...@chromium.org>>
Subject: Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome



On Thu, Aug 11, 2022 at 5:43 PM Sasha Tokarev 
mailto:alex...@microsoft.com>> wrote:
Hi Matt,

I apologize for not being able to respond, I was on vacation, but now I’m back. 
However, before the vacation, I had planned to ping this thread, as we are 
getting more and more feedback that the extension model is not working for 
various reasons, and the users do not have sufficient help to resolve it. In 
many cases the extension is either accidentally dismissed, or partially works 
(has icon on tab, but the rest functionality is blocked). In such cases we 
suggest to escalate to Google, but I’ve been seeing very few cases that 
successfully got attention from Google.

You can read review feedback here:

https://chrome.google.com/webstore/detail/windows-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji<https://nam06.safelinks.protection.outlook.com/?url=http

Re: [blink-dev] RE: [EXTERNAL] Re: Native support of Windows SSO in Chrome

[John Abd-El-Malek]

Hi Sasha, I got looped in to a code review and I had a few questions:

1) Can we avoid modifying the Cookie header, and only modify "x-ms-"
headers?
2) Can this be scoped to just frame requests, e.g. only for requests to
fetch the html for main frames and subframes and not subresource requests
like images, XHR, JS, CSS etc. requests? Igor had tried this locally and it
seemed to work.

If we can do the above, either right away or with small changes to your
server, we can simplify the implementation in Chrome. This in turn would
help us reach a lower maintenance burden while still being performant.

Thanks

On Thu, Aug 11, 2022 at 4:30 PM 'Sasha Tokarev' via blink-dev <
blink-dev@chromium.org> wrote:

> With respect to credential mode “omit” it is fine not send those headers,
> if the other mode will allow it.
>
>
>
> We use sandboxed iframes in out authentication libs, but we set
> “allow-same-origin” token to be able to use cookies.
>
>
>
>
> https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/6756b300c5696ad4890f1f7f27de69f6941a71e7/lib/msal-browser/src/interaction_handler/SilentHandler.ts#L143
>
>
>
> We fine if “allow-same-origin” will relax restriction of not sending
> cookies.
>
>
>
>
> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-sandbox
>
>
>
> Thank you,
>
> Sasha
>
>
>
> *From:* Matt Menke 
> *Sent:* Thursday, August 11, 2022 3:09 PM
> *To:* Sasha Tokarev 
> *Cc:* blink-dev ; Owen Min ;
> Greg Thompson ; Ryan Sleevi ;
> Adam Langley 
> *Subject:* Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome
>
>
>
>
>
>
>
> On Thu, Aug 11, 2022 at 5:43 PM Sasha Tokarev 
> wrote:
>
> Hi Matt,
>
>
>
> I apologize for not being able to respond, I was on vacation, but now I’m
> back. However, before the vacation, I had planned to ping this thread, as
> we are getting more and more feedback that the extension model is not
> working for various reasons, and the users do not have sufficient help to
> resolve it. In many cases the extension is either accidentally dismissed,
> or partially works (has icon on tab, but the rest functionality is
> blocked). In such cases we suggest to escalate to Google, but I’ve been
> seeing very few cases that successfully got attention from Google.
>
>
>
> You can read review feedback here:
>
>
>
>
> https://chrome.google.com/webstore/detail/windows-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji
> 
>
>
>
> In such cases the only recommendation we have is “use Edge”, as it has the
> native support and not a subject for the extension deployment issues.  In
> order to reduce support cost, we are also considering to change our
> remediation page, which we show when the users hit the conditional access
> issues, to detect such cases and show more explicit text to use Edge. I’m
> hopping we will be able to make a progress on this.
>
>
>
> Back to your question:
>
> * Do we need to bypass CORS for requests send to Microsoft's IDP?
>
> - no you don’t need. It is ok to respect CORS.
>
>
>
> * Do we need to send Microsoft SSO credentials in Credentials Mode: Omit
> requests?
>
> - I assume you meant this XHR requests with credentials?
> https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#requests_with_credentials
> 
>
> We don’t use XHR for authentication for now. So, if it is
> more simple, we can agree on “no”.
>
>
>
> No, I mean any request with a credentials mode of omit.  See
> https://fetch.spec.whatwg.org/#concept-request-credentials-mode
> .
> That's a fetch layer concept, not something unique to XHRs.
>
>
>
>
>
> * Do we need to send SSO credentials in sandbo

[blink-dev] RE: [EXTERNAL] Re: Native support of Windows SSO in Chrome

['Sasha Tokarev' via blink-dev]

With respect to credential mode “omit” it is fine not send those headers, if 
the other mode will allow it.

We use sandboxed iframes in out authentication libs, but we set 
“allow-same-origin” token to be able to use cookies.

https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/6756b300c5696ad4890f1f7f27de69f6941a71e7/lib/msal-browser/src/interaction_handler/SilentHandler.ts#L143

We fine if “allow-same-origin” will relax restriction of not sending cookies.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-sandbox

Thank you,
Sasha

From: Matt Menke 
Sent: Thursday, August 11, 2022 3:09 PM
To: Sasha Tokarev 
Cc: blink-dev ; Owen Min ; Greg 
Thompson ; Ryan Sleevi ; Adam Langley 

Subject: Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome



On Thu, Aug 11, 2022 at 5:43 PM Sasha Tokarev 
mailto:alex...@microsoft.com>> wrote:
Hi Matt,

I apologize for not being able to respond, I was on vacation, but now I’m back. 
However, before the vacation, I had planned to ping this thread, as we are 
getting more and more feedback that the extension model is not working for 
various reasons, and the users do not have sufficient help to resolve it. In 
many cases the extension is either accidentally dismissed, or partially works 
(has icon on tab, but the rest functionality is blocked). In such cases we 
suggest to escalate to Google, but I’ve been seeing very few cases that 
successfully got attention from Google.

You can read review feedback here:

https://chrome.google.com/webstore/detail/windows-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji

In such cases the only recommendation we have is “use Edge”, as it has the 
native support and not a subject for the extension deployment issues.  In order 
to reduce support cost, we are also considering to change our remediation page, 
which we show when the users hit the conditional access issues, to detect such 
cases and show more explicit text to use Edge. I’m hopping we will be able to 
make a progress on this.

Back to your question:
* Do we need to bypass CORS for requests send to Microsoft's IDP?
- no you don’t need. It is ok to respect CORS.

* Do we need to send Microsoft SSO credentials in Credentials Mode: Omit 
requests?
- I assume you meant this XHR requests with credentials? 
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#requests_with_credentials
We don’t use XHR for authentication for now. So, if it is more 
simple, we can agree on “no”.

No, I mean any request with a credentials mode of omit.  See 
https://fetch.spec.whatwg.org/#concept-request-credentials-mode.
  That's a fetch layer concept, not something unique to XHRs.


* Do we need to send SSO credentials in sandboxed iframes of fenced frames?
   - no. I’ve synced up internally, we don’t use fenced frames, but 
we use iframes (on the application page) for some authentications. So, this 
headers should be available in iframes of the application page.

So what about sandboxed iframes?  They don't have cookie access, normally.


Thank you,
Sasha

From: Matt Menke mme...@chromium.org
Sent: Wednesday, July 20, 2022 8:52 AM
To: blink-dev mailto:blink-dev@chromium.org>>
Cc: Sasha Tokarev mailto:alex...@microsoft.com>>; Owen 
Min mailto:z...@chromium.org>>; blink-dev 
mailto:blink-dev@chromium.org>>; Greg Thompson 
mailto:g...@chromium.org>>; Ryan Sleevi 
mailto:rsle...@chromium.org>>; Adam Langley 
mailto:a...@chromium.org>>; Matt Menke 
mailto:mme...@chromium.org>>
Subject: Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome

This t

[blink-dev] Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome

[Matt Menke]

On Thu, Aug 11, 2022 at 5:43 PM Sasha Tokarev  wrote:

> Hi Matt,
>
>
>
> I apologize for not being able to respond, I was on vacation, but now I’m
> back. However, before the vacation, I had planned to ping this thread, as
> we are getting more and more feedback that the extension model is not
> working for various reasons, and the users do not have sufficient help to
> resolve it. In many cases the extension is either accidentally dismissed,
> or partially works (has icon on tab, but the rest functionality is
> blocked). In such cases we suggest to escalate to Google, but I’ve been
> seeing very few cases that successfully got attention from Google.
>
>
>
> You can read review feedback here:
>
>
>
>
> https://chrome.google.com/webstore/detail/windows-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji
>
>
>
> In such cases the only recommendation we have is “use Edge”, as it has the
> native support and not a subject for the extension deployment issues.  In
> order to reduce support cost, we are also considering to change our
> remediation page, which we show when the users hit the conditional access
> issues, to detect such cases and show more explicit text to use Edge. I’m
> hopping we will be able to make a progress on this.
>
>
>
> Back to your question:
>
> * Do we need to bypass CORS for requests send to Microsoft's IDP?
>
> - no you don’t need. It is ok to respect CORS.
>
>
>
> * Do we need to send Microsoft SSO credentials in Credentials Mode: Omit
> requests?
>
> - I assume you meant this XHR requests with credentials?
> https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#requests_with_credentials
>
> We don’t use XHR for authentication for now. So, if it is
> more simple, we can agree on “no”.
>

No, I mean any request with a credentials mode of omit.  See
https://fetch.spec.whatwg.org/#concept-request-credentials-mode.  That's a
fetch layer concept, not something unique to XHRs.


>
>
> * Do we need to send SSO credentials in sandboxed iframes of fenced frames?
>
>- no. I’ve synced up internally, we don’t use fenced
> frames, but we use iframes (on the application page) for some
> authentications. So, this headers should be available in iframes of the
> application page.
>

So what about sandboxed iframes?  They don't have cookie access, normally.


>
>
> Thank you,
>
> Sasha
>
>
>
> *From:* Matt Menke mme...@chromium.org
> *Sent:* Wednesday, July 20, 2022 8:52 AM
> *To:* blink-dev 
> *Cc:* Sasha Tokarev ; Owen Min ;
> blink-dev ; Greg Thompson ;
> Ryan Sleevi ; Adam Langley ; Matt
> Menke 
> *Subject:* Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome
>
>
>
> This task is being picked up again, but there are a lot of questions in
> terms of implementation:
>
>
>
> * Do we need to send Microsoft SSO credentials in Credentials Mode: Omit
> requests?
>
> * Do we need to bypass CORS for requests send to Microsoft's IDP?  This is
> a bit related to the above question.
>
> * Do we need to send SSO credentials in sandboxed iframes of fenced frames?
>
>
>
> I'm hoping the answer to all of these is "no", so these behave a bit like
> 3P cookies (which are being removed from the web platform...).
>
> On Wednesday, November 3, 2021 at 11:12:16 AM UTC-4 Sasha Tokarev wrote:
>
> (Sorry for duplication, but I don’t see this response in the public
> thread, probably because I’ve sent it from my private email and it went to
> some filters, so I’m repeating it from my official with some *additions*)
>
>
>
> I would like to highlight one important conception of “joined device". If
> a user/admin went through the joining process, they *consented* and
> expect:
>
>
>
>1. browser SSO
>2. application SSO
>3. access to protected services from *a web and a native applications*
>
>
>
> Otherwise, they should not join.
>
>
>
> While privacy and security concerns are important, we should agree that it
> is IDP job to balance all parties in process *of authentication*, and
> they always exist, given we have centralized identity service, and IDP use
> cookies.
>
>
>
> *Joining of the device is an explicit, and in some case not a trivial
> action from a device owner (in case of personal devices the device owner ==
> the user), an extra flag in this process makes this feature unusable for
> some cases. With respect to security and privacy aspects, there is no
> essential difference in the IDP behavior between a web application and a
> native application (browser SSO and application SSO),  if the device owner
> doesn’t like the IDP behavior, he/she needs to unjoin.  *
>
>
>
> Thank you,
>
> Sasha
>
>
>
>
>
> *From:* Sasha Tokarev
> *Sent:* Tuesday, November 2, 2021 6:33 PM
> *To:* 'Matt Menke' 
> *Cc:* Owen Min ; blink-dev ;
> Greg Thompson ; Ryan Sleevi ;
> Adam Langley 
> *Subject:* RE: [EXTERNAL] Re: Native support of Windows SSO in Chrome
>
>
>
> Hi Matt,
>
>
>
> I missed that you asked some questions inline, sorry about that, I’ll
> cover answers *inline* as 

[blink-dev] RE: [EXTERNAL] Re: Native support of Windows SSO in Chrome

['Sasha Tokarev' via blink-dev]

Hi Matt,

I apologize for not being able to respond, I was on vacation, but now I’m back. 
However, before the vacation, I had planned to ping this thread, as we are 
getting more and more feedback that the extension model is not working for 
various reasons, and the users do not have sufficient help to resolve it. In 
many cases the extension is either accidentally dismissed, or partially works 
(has icon on tab, but the rest functionality is blocked). In such cases we 
suggest to escalate to Google, but I’ve been seeing very few cases that 
successfully got attention from Google.

You can read review feedback here:

https://chrome.google.com/webstore/detail/windows-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji

In such cases the only recommendation we have is “use Edge”, as it has the 
native support and not a subject for the extension deployment issues.  In order 
to reduce support cost, we are also considering to change our remediation page, 
which we show when the users hit the conditional access issues, to detect such 
cases and show more explicit text to use Edge. I’m hopping we will be able to 
make a progress on this.

Back to your question:
* Do we need to bypass CORS for requests send to Microsoft's IDP?
- no you don’t need. It is ok to respect CORS.

* Do we need to send Microsoft SSO credentials in Credentials Mode: Omit 
requests?
- I assume you meant this XHR requests with credentials? 
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#requests_with_credentials
We don’t use XHR for authentication for now. So, if it is more 
simple, we can agree on “no”.

* Do we need to send SSO credentials in sandboxed iframes of fenced frames?
   - no. I’ve synced up internally, we don’t use fenced frames, but 
we use iframes (on the application page) for some authentications. So, this 
headers should be available in iframes of the application page.

Thank you,
Sasha

From: Matt Menke mme...@chromium.org
Sent: Wednesday, July 20, 2022 8:52 AM
To: blink-dev 
Cc: Sasha Tokarev ; Owen Min ; 
blink-dev ; Greg Thompson ; Ryan 
Sleevi ; Adam Langley ; Matt Menke 

Subject: Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome

This task is being picked up again, but there are a lot of questions in terms 
of implementation:

* Do we need to send Microsoft SSO credentials in Credentials Mode: Omit 
requests?
* Do we need to bypass CORS for requests send to Microsoft's IDP?  This is a 
bit related to the above question.
* Do we need to send SSO credentials in sandboxed iframes of fenced frames?

I'm hoping the answer to all of these is "no", so these behave a bit like 3P 
cookies (which are being removed from the web platform...).
On Wednesday, November 3, 2021 at 11:12:16 AM UTC-4 Sasha Tokarev wrote:
(Sorry for duplication, but I don’t see this response in the public thread, 
probably because I’ve sent it from my private email and it went to some 
filters, so I’m repeating it from my official with some additions)


I would like to highlight one important conception of “joined device". If a 
user/admin went through the joining process, they consented and expect:



  1.  browser SSO
  2.  application SSO
  3.  access to protected services from a web and a native applications



Otherwise, they should not join.



While privacy and security concerns are important, we should agree that it is 
IDP job to balance all parties in process of authentication, and they always 
exist, given we have centralized identity service, and IDP use cookies.



Joining of the device is an explicit, and in some case not a trivial action 
from a device owner (in case of personal devices the device owner == the user), 
an extra flag in this process makes this feature unusable for some cases. With 
respect to security and privacy aspects, there is no essential difference in 
the IDP behavior between a web application and a native application (browser 
SSO and application SSO),  if the device owner doesn’t like the IDP behavior, 
he/she needs to unjoin.



Thank you,

Sasha


From: Sasha Tokarev
Sent: Tuesday, November 2, 2021 6:33 PM
To: 'Matt Menke' mailto:mme...@chromium.org>>
Cc: Owen Min mailto:z...@chromium.org>>; blink-dev 
mailto:blink-dev@chromium.org>>; Greg Thompson 
mailto:g...@chromium.org>>; Ryan Sleevi 
mailto:rsle...@chromium.org>>; Adam Langley 
mailto:a...@chromium.org>>
Subject: RE: [EXTERNAL] Re: Native support of Windows SSO in Chrome

Hi Matt,

I missed that you asked some questions inline, sorry about that, I’ll cover 
answers inline as well.

From: Matt Menke mailto:mme...@chromium.org>>
Sent: Saturday, September 25, 2021 7:45 PM
To: Sasha Tokarev mailto:alex...@microsoft.com>>
Cc: Owen Min mailto:z...@chromium.org>>; blink-dev 
mailto:blink-dev@chromium.org>>; Greg Thompson 
mailto:g...@chromium.org>>; Ryan Sleevi 
mailto:rsle...@chromium.org>>; Adam Langley 
mailto:a...@chromium.org>>
Subject: Re: [EXTERNAL] Re: Native support of Windows

[blink-dev] Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome

[Matt Menke]

This task is being picked up again, but there are a lot of questions in 
terms of implementation:

* Do we need to send Microsoft SSO credentials in Credentials Mode: Omit 
requests?
* Do we need to bypass CORS for requests send to Microsoft's IDP?  This is 
a bit related to the above question.
* Do we need to send SSO credentials in sandboxed iframes of fenced frames?

I'm hoping the answer to all of these is "no", so these behave a bit like 
3P cookies (which are being removed from the web platform...).
On Wednesday, November 3, 2021 at 11:12:16 AM UTC-4 Sasha Tokarev wrote:

> (Sorry for duplication, but I don’t see this response in the public 
> thread, probably because I’ve sent it from my private email and it went to 
> some filters, so I’m repeating it from my official with some *additions*)
>
>  
>
> I would like to highlight one important conception of “joined device". If 
> a user/admin went through the joining process, they *consented* and 
> expect:
>
>  
>
>1. browser SSO
>2. application SSO
>3. access to protected services from *a web and a native applications*
>
>  
>
> Otherwise, they should not join. 
>
>  
>
> While privacy and security concerns are important, we should agree that it 
> is IDP job to balance all parties in process *of authentication*, and 
> they always exist, given we have centralized identity service, and IDP use 
> cookies. 
>
>  
>
> *Joining of the device is an explicit, and in some case not a trivial 
> action from a device owner (in case of personal devices the device owner == 
> the user), an extra flag in this process makes this feature unusable for 
> some cases. With respect to security and privacy aspects, there is no 
> essential difference in the IDP behavior between a web application and a 
> native application (browser SSO and application SSO),  if the device owner 
> doesn’t like the IDP behavior, he/she needs to unjoin.  *
>
>  
>
> Thank you,
>
> Sasha
>
>  
>
>  
>
> *From:* Sasha Tokarev 
> *Sent:* Tuesday, November 2, 2021 6:33 PM
> *To:* 'Matt Menke' 
> *Cc:* Owen Min ; blink-dev ; 
> Greg Thompson ; Ryan Sleevi ; 
> Adam Langley 
> *Subject:* RE: [EXTERNAL] Re: Native support of Windows SSO in Chrome
>
>  
>
> Hi Matt,
>
>  
>
> I missed that you asked some questions inline, sorry about that, I’ll 
> cover answers *inline* as well.
>
>  
>
> *From:* Matt Menke  
> *Sent:* Saturday, September 25, 2021 7:45 PM
> *To:* Sasha Tokarev 
> *Cc:* Owen Min ; blink-dev ; 
> Greg Thompson ; Ryan Sleevi ; 
> Adam Langley 
> *Subject:* Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome
>
>  
>
> Thanks for the details, Sasha!  Please don't feel like you need to answer 
> my questions while on vacation - there's no rush here.
>
>  
>
> Enjoy your vacation!
>
>  
>
> On Sat, Sep 25, 2021 at 9:22 PM Sasha Tokarev  
> wrote:
>
> Hi Matt,
>
>  
>
> Disclaimer: I’m at vacation my responses may delay.
>
>  
>
> *> What's the flow to join a cloud identity here?  What are the permission 
> prompts like?  I assume that home users who use generic home user Microsoft 
> accounts (as I believe encouraged during Windows install/configuration) 
> aren't assumed to be granting this permission, though it could reasonably 
> be described as a "device joined to cloud identity"?*
>
>  
>
> There are many ways of joining devices, many of them looks like domain 
> joining, and requires admin’s action and explicit user action. Home user 
> also either go via explicit action and consent which include web SSO:
>
> [image: Graphical user interface, text, application Description 
> automatically generated]
>
>  
>
> Thanks!  So this is a per-local-app permission, that can also be 
> granted to all apps? (*Sasha: yes, if the user consents)*  My main 
> concerns, in terms of privacy (not security issues) here are:
>
>  
>
>1. Home user using a Microsoft account on their personal device 
>unexpectedly gets logged in.  If the user has to give explicit permission 
>to Chrome or all apps (apart from just using a Microsoft account), as it 
>sounds like is the case, I'm much less concerned about this.  I'd still be 
>more comfortable if Chrome-side integration is disabled by default, though 
>the settings folk may not think it's worth a new setting. 
>
>  
>
> *Sasha: An extra settings just an extra friction, the user has consented, 
> and user expects SSO, otherwise it should not join the device.*
>
>  
>
> 2)  An enterprise uses corp Microsoft accounts, but doesn't want to use 
> Microsoft as an IDP. (*Sasha: it should not join device to Microsoft IDP 
> then)*   It may not want this information to be sent to Microsoft.  
> Admittedly, I'm not sure how much of a concern this is, if Microsoft is 
> managing their accounts in the first place.  Note that I'd be concerned 
> about this happening for non-Microsoft managed accounts here, too, just 
> think it's less likely for it to be possible to accidentally happen for 
> non-Microsoft accounts.  Sounds 

[blink-dev] RE: [EXTERNAL] Re: Native support of Windows SSO in Chrome

['Sasha Tokarev' via blink-dev]

Hi Ryan,

Thank you for the chat.

Couple notes from me:


> If this is solely relegated to an Enterprise flag (and not even a user 
> preference), I certainly am far less worried.

I think it will be very far from ideal,  key part is that the user has joined 
his device and consented for SSO. They expect SSO. Having extra flag just extra 
useless hop, which adds friction without value. If users do not want to have 
SSO, they should not join. Extra policy/switch will kill authentication in 
Chrome for small businesses, because they will not know how to enable it, many 
organizations do not have big investment in IT department, as well as they 
allow use users’ personal devices, on which IT has limited control to enable 
some flag remotely. As a result it will make Chrome less attractive for such 
businesses.

> there have long been discussions about moving the entire authentication stack 
> itself behind policy-gates

Discussion is one thing, but you haven’t done it, right? As Chrome will lost 
its attractiveness because IT folks will have to jump via extra hops, most 
likely will not find how to do it, and user have to switch on working browsers.

> … My worry is the pressures to more generally expose this (e.g. a user-level 
> preference or a default-on) will, similar to the "lost decade" of 
> NTLM/Kerberos interop online, end up with a de-facto standard that isn't well 
> defined as to how it integrates.

The key difference here from other public auth schemes, that in a public auth 
protocol there is an assumption that somebody will implement those schemes, and 
an enterprise can setup a web auth service created by 3p developer. In the new 
approach it just us, we should validate our stuff, the rest of world integrates 
with us by OAuth. In a public auth protocol you need an extensive documentation 
and think what a behavior of web browser should be if an auth web server 
behavior is not legitimate. In the proposed scheme, you have only couple 
well-known IDPs, which you can easily identify, the behavior is well defined 
and documented. You can monitor and contact IDP any time. It is not 1000s of 
servers who implements kerberos worldwide, it just 2 services. 
Format/documentation of cookie-header has low relevance here, as it is our 
internal details.

> note that Chrome has already moved (similar to Edge) to restrict/disallow 
> this in Incognito

Totally agree on this!

I think we could take Edge’s idea:

  1.  default/first profile has this feature on.
  2.  A secondary profile - by default off, but has a setting to turn it on.
  3.  Incognito – can behave as a secondary or have some registry.

We also can discuss how to create profile for a different WebAccounts that you 
have on the system.

> It looks like Mozilla had similar concerns

Some of Mozilla concerns are the same, but some are different - I’m aware all 
of them, as I’m involved in that project as well. Regardless of their concerns 
- they shipped the first click stop.

With respect to documentation/header names, it is important for me to 
understand your commitments for this. As it is not cheap, if Chrome going to 
commit in this, we can discuss what is important for you, and do it fast, 
otherwise we will do it in our own pace.

> conditional access can be also viewed as a form of browser/vendor lock-in 
> (which, as you note, may already be practiced, but not necessarily good)

I have multiple interpretation of this phrase in my head, but I’ll try to 
respond what I think is the most likely one. If it is about having some 
client-side code that prevents from some access (client-side security) it easy 
to work around by patching the code. Whatever we build, as well as some other 
vendors, we deliver device id to the server, and the server decides “issues/not 
issues token” based on the state of device, and its history. It is way harder 
to compromise many signals that comes from device over time vs patching the 
client code.

> the binding to device identity equally normalizes persistent online tracking 
> in ways that may be coopted for less-than-noble purposes (e.g. attempts to 
> legislate out online anonymity)

I think it is important to highlight here, that IDP knows device (and the user 
has consented it), but the calling web-application not mandatory (it really 
depends what IDP renders in the token). I share your device online anonymity 
(that is why I agree that in Incognito mode we should have this stuff off), but 
our job is keeping balances between privacy, security, and features. If the 
user has made the extra steps to join the device to IDP, then I don’t think we 
should challenge that user made a wrong decision. The users always can unjoin, 
if they do not trust IDP, or IDP compromised their trust.

> the primary way of doing that is through encouraging greater centralization 
> of identity services.

And this where this feature will help 😊

Thank you,
Sasha

From: Ryan Sleevi 
Sent: Tuesday, October 26, 2021 12:03 PM

[blink-dev] Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome

[Ryan Sleevi]

On Tue, Oct 26, 2021 at 2:34 PM Sasha Tokarev  wrote:

> I think it is true for any authentication that part of Chrome, like
> Digest, Client TLS, Windows Integrated (NTLMv2, Kerberos) etc. I think the
> cookie cleanup will not prevent a web site that performs Windows Integrated
> authentication to know who you are. In this aspect it is a new form of
> Windows Integrated authentication, but more secure. I think Chrome
> implements Windows Integrated authentication as well as other forms of
> authentication, and not really concerned about it. From the other hand, a
> web app that integrated with IDP will lost its cookies and state on the
> cookie cleanup, and will have to start authentication process again,
> redirect to IDP, account consent if needed, etc. We also can discuss how we
> can support different browser profiles in this area.
>

The comparison here to the other forms of OS auth is totally apt. However,
note that Chrome has already moved (similar to Edge) to restrict/disallow
this in Incognito, and there have long been discussions about moving the
entire authentication stack itself behind policy-gates, precisely because
for the general user, it represents a privacy and security risk. Some of
that calculus is further informed by the openness and well-definedness of
the protocols implemented, and the ability to assess their relative
security merits; e.g. NTLM is seen as a greater security risk to users due
to its limits on "server" authentication, compared to Kerberos (e.g. via
SPN binding). And, similarly, Negotiate is seen as a risk because of the
ability to introduce mechanisms that may otherwise contravene local
policies (e.g. if you disable NTLM, but the Negotiate provider still
enables it).

Of course, the existing auth methods also reveal some of the complexity I
worry about. NTLM/Kerberos/Negotiate using a three-leg auth system means
that it's incompatible with HTTP/2 and, similarly, incompatible with
HTTP/3. This creates a fair bit of negative incentives for organizations:
you can have a modern application, or you can have integrated SSO, but you
can't have both. Of course, that realization of incompatibility was only
possible due to the fairly open and extensive documentation of the
protocols. I don't mean this to sound too negative; again, you've been
incredibly helpful :) It's just one of those headwinds to be mindful of in
trying to figure out how to rationalize this, since as a "cookie-or-header"
side, there are plenty of implementation worries.

It looks like Mozilla had similar concerns - e.g.
https://bugzilla.mozilla.org/show_bug.cgi?id=1695693#c9 and
https://phabricator.services.mozilla.com/D114540#3798290 , so I feel a
little better :) They also highlighted an area of reasonable concern
regarding IDNA treatment that I totally overlooked too, not to mention the
header correctness.


> Overall, I would like to highlight this model is not only about SSO, SSO
> is a tip of the iceberg, we build a lot of features on it:
>
>
>
>1. Conditional access — granular control of access to the cloud
>resources (mentioned above).
>2. Enables protection of Identity artifacts against man-in-the-middle
>attacks by allowing Identity provider to issue shorter lived tokens that
>are bound to the device identity.
>3. Preventing extra password and 2FA prompt, minimizes the need for
>sending user’s password on the wire continuously.
>
> Right, but these are both benefits and risks. Not trying to be contrarian
so much as capture a different perspective, but conditional access can be
also viewed as a form of browser/vendor lock-in (which, as you note, may
already be practiced, but not necessarily good), the binding to device
identity equally normalizes persistent online tracking in ways that may be
coopted for less-than-noble purposes (e.g. attempts to legislate out online
anonymity), and while you're certainly correct that reducing prompts is a
great way to reduce fatigue while improving the security story for the
underlying auth, the primary way of doing that is through encouraging
greater centralization of identity services. These aren't to discredit the
idea, but to highlight the risks, and the challenge in finding the balance.


>1. Missing documentation – we Microsoft, planning to publish code on
>github and fix documentation, to allow other browser to integrate.
>2. X-ms- headers – if needed we can agree on different header names,
>or remove x-ms- prefix 😊
>
> It looked like Mozilla also raised this concern, so it seems to be a clear
need to address.


> “This sort of thing doesn't have a path towards standardization or
> interoperability” — at this stage, other players already integrated with
> it, or have similar model (only Chrome, and Android doesn’t have similar
> model). Once we fix the documentation Opera and others will fix their
> browsers as well. Our extensions in total have 20M+ users – there is big
> demand on this. I don’t think this concern 

[blink-dev] RE: [EXTERNAL] Re: Native support of Windows SSO in Chrome

['Sasha Tokarev' via blink-dev]

Hy Ryan,

Sorry for the delay and thank you for open discussion.

I would like to start from the simple point:
> it means clearing cookies in Chrome may no longer clear cookies, because 
> these IDP APIs may hold on to them.

I think it is true for any authentication that part of Chrome, like Digest, 
Client TLS, Windows Integrated (NTLMv2, Kerberos) etc. I think the cookie 
cleanup will not prevent a web site that performs Windows Integrated 
authentication to know who you are. In this aspect it is a new form of Windows 
Integrated authentication, but more secure. I think Chrome implements Windows 
Integrated authentication as well as other forms of authentication, and not 
really concerned about it. From the other hand, a web app that integrated with 
IDP will lost its cookies and state on the cookie cleanup, and will have to 
start authentication process again, redirect to IDP, account consent if needed, 
etc. We also can discuss how we can support different browser profiles in this 
area.

One part that I haven’t covered yet, that those headers/cookies have device id 
inside, and admins have tools to enable access to their resources based on the 
state of device. For example, they can allow to access to SharePoint, only if a 
user’s device is compliant (has the latest updates and satisfy other company’s 
requirements).  Most Microsoft customers enjoy using conditional access 
policies to protect their cloud resources. These policies are widely used 
because they allow granular control of cloud assets. However, if cookies were 
not reliably delivered, then the users are blocked and entering password will 
not help — the users will be permanently blocked. The users cannot utilize 
Chrome as is, because Chrome cannot deliver device information to the identity 
service for the policy evaluation. Depends on platform, the users have multiple 
options to unblock themselves:


  1.  Use Chromium Edge — given that HTML engine is the same between Chrome and 
Edge they do not lose anything.
  2.  Use FireFox, which has already integration with this feature ( 
https://support.mozilla.org/en-US/kb/windows-sso )
  3.  Install one of our Chrome extensions (for example this one 
https://chrome.google.com/webstore/detail/windows-10-accounts/ppnbnpeolgkicgegkbkbjmhlideopiji),
 which uses native messaging host to integrate with this API.
  4.  For MacOS, iOS use Safari, as iOS, Apple supports alternative, but 
similar functionality:
ASAuthorizationSingleSignOnProvider | Apple Developer 
Documentation
WebKit/SOAuthorizationCoordinator.mm at main · WebKit/WebKit 
(github.com)

With respect to the extension model, it is naturally more complex, because it 
must consider 3P code, as a result has more failure points. Unfortunately, 
support story for the extensions is painful for us and our customers, and when 
we say people escalate to Google, they say that they cannot, and choose other 
options. Overall Chrome users experience degraded single sign on experience 
compared to Edge, FireFox or Safari population. They must pass extra 2FA and 
password prompts, unless they use the extension, while Edge, Safari and FireFox 
the users can skip these interrupts, if they used strong Windows logon 
credentials or passed 2FA in other applications (like Teams, Outlook etc.).

Overall, I would like to highlight this model is not only about SSO, SSO is a 
tip of the iceberg, we build a lot of features on it:


  1.  Conditional access — granular control of access to the cloud resources 
(mentioned above).
  2.  Enables protection of Identity artifacts against man-in-the-middle 
attacks by allowing Identity provider to issue shorter lived tokens that are 
bound to the device identity.
  3.  Preventing extra password and 2FA prompt, minimizes the need for sending 
user’s password on the wire continuously.

As you already have noted, FireFox, Safari, Apple platform already supports 
this feature or similar feature,  and we in constant collaboration with them. I 
agree with you, that there is lack of documentation and standardization, but 
the key players actively work on this, and it doesn’t stop them. I would like 
us to focus on the finding path forward, which from one hand will put Chrome on 
parity with Edge, Safari and FireFox at this aspect, from the other hand will 
formalize and find a path to close the gaps you mentioned:


  1.  Missing documentation – we Microsoft, planning to publish code on github 
and fix documentation, to allow other browser to integrate.
  2.  X-ms- headers – if needed we can agree on different header names, or 
remove x-ms- prefix 😊
  3.  3P integration — for now there is no 3P, as 3Ps are not willing, and they 
cannot appear without work on our end. Once 3P will express their

[blink-dev] Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome

[Ryan Sleevi]

Thanks Sasha!

TL;DR: I think we've got enough information here to make a decision. You've
been *incredibly* *helpful* for that. What follows is my personal views,
not a decision, and I share them not to shut down the conversation, but
instead, to keep the conversation going and to continue to move us closer
to a conclusion :)

Speaking personally, I'd be worried about implementing this in Chromium.
You've been *incredibly* helpful here in helping understand, but I worry
this highlights a worrying lack of documentation here, as well as a lack of
holistic integration into the Web Platform. Extensions obviously have
incredible power and flexibility, and can "break" the assumptions of the
Web Platform in many ways, to both the delight (e.g. introducing new
features) and consternation (e.g. breaking existing features) of users. Yet
as extensions, it's also an area where it's "not our problem" to support.

That seems like I'm arguing we (Chromium) shouldn't do it because it means
more work for us, but that's not quite where I'm going. Rather, to
integrate this into Chromium means making sure Chromium developers have the
knowledge to understand and reason about how this will interact with the
Web Platform, how the Web Platform can co-evolve with features like this,
and how it fits overall into Chromium's 4 S's (Simplicity, Speed, Security,
Stability). In particular, I think as mmenke@ alluded to, this makes it
difficult to reason about privacy properties: for example, it means
clearing cookies in Chrome may no longer clear cookies, because these IDP
APIs may hold on to them. For things like the effort to safely partition
and isolate cookies, this means it's difficult to reason about how these
APIs behave in 1P vs 3P contexts. In terms of stability, this seems
intended to be an extensible platform, and thus potentially brings more 3P
code into whatever process implements this (the proposals, at present, are
for the browser process, due to network service sandboxing). When we think
about how potential 3P (non-MS) IdPs would use this API, it sounds like
that this would de facto mean that they'd need to use "x-ms-" as a prefix
for their headers, and that, similarly, there's a lack of way to feed back
in to the IdP the state of the user as to whether headers-or-cookies should
be used.

I appreciate Microsoft's attempt to provide some isolation for the Web from
their experimental headers ("x-"), but as RFC 6648 Section 3 highlights,
this doesn't really work in practice, and the use of "x-" headers doesn't
really prevent them from becoming de facto standards (as the previous
remark highlights).

My worry is that if directly implemented in Chromium, these all become
concerns Chromium needs to worry about, and Chromium needs to support and
address. We can't just remove a feature when it gets difficult, or there
isn't sufficient documentation, and while I'm not trying to suggest we can
arbitrarily break extensions either, we don't necessarily have to reason
about every extension's behaviour prior to making any changes to Chromium,
like we do need to do with Chromium features. For users, "Chromium is
broken", and there's not an option to point out that "no, the extension is
broken" as there is today.

I do worry that because this flow can only really be implemented in
conjunction with Windows (and WAM), it makes it easy for websites to
construct experiences that "Work best with Edge" or, if Chromium
implements, "Work best with Chromium". For example, if an internal website
required these assertions, then they would not work with Firefox - unless
the user installed the extension or unless Firefox also integrated with
Microsoft's proprietary APIs. While it's certainly true that an internal
website (or IdP) could provide a "fallback path" for a "less" secure
browser (i.e. one that doesn't provide TPM-bound cookies), I think
practical experience of enterprises in the past suggest that may be less
likely.

I'm very concerned that this sort of thing doesn't have a path towards
standardization or interoperability. I realize that, in part, this approach
to WAM is a reflection of the fact that Token Binding shared many of these
limitations, and we intentionally removed Token Binding precisely because
of its incompatibility with, and lack of explaininability with, the overall
Web Platform. This is conceptually similar in the challenges, but with even
less multi-stakeholder agreement or interoperable specification, and so
that does worry me. Similarly, I do worry that this favors a particular IdP
being able to offer both technical solutions and ease of use over those of
others, both because at least one IdP will always work "out of the box" on
some OSes, but also because the access to change those requirements as
needed (e.g. the shift from cookies to headers) that other IdPs can't
easily do.

But that's just my opinion, and I certainly wouldn't be the one to have
final say here, especially since I'm known for taking the most critica

[blink-dev] RE: [EXTERNAL] Re: Native support of Windows SSO in Chrome

['Sasha Tokarev' via blink-dev]

Hi all,

You are correct with respect to cookie size limit. Because there is a 4k limit 
for all cookies, when we introduced multiple accounts, we hit this limit and 
some proxies started to block our requests. That why we changed our cookies to 
headers.

Right now, IProofOfPossessionCookieInfoManager::GetCookieInfoForUri can return 
either a list of cookies or a list of headers.

GET 
https://login.microsoftonline.com/common/oauth2/authorize?response_type=code&client_id=1fec8e78-bce4-4aaf-ab1b-5451cc387264&redirect_uri=ms-appx-web%3a%2f%2fMicrosoft.AAD.BrokerPlugin%2f1fec8e78-bce4-4aaf-ab1b-5451cc387264&resource=https%3a%2f%2fapi.spaces.skype.com&add_account=multiple&login_hint=aaa%40microsoft.com&response_mode=form_post&windows_api_version=2.0
 HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
(KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.21329
x-ms-DeviceCredential: eyJhbGciOiJSUzI1NiIsICJ0eXAiOiJKV1QiLCAieDVjI...
x-ms-RefreshTokenCredential: 
eyJrZGZfdmVyIjoyLCJjdHgiOiIyckJrVzcxQzFCSjg1Q1ZSSWtlWmRmYklReW9...
x-ms-DeviceCredential1: eyJhbGciOiJSUzI1NiIsICJ0eXAiOiJKV1QiLCAieDVjI...
x-ms-RefreshTokenCredential1: 
eyJrZGZfdmVyIjoyLCJjdHgiOiIyckJrVzcxQzFCSjg1Q1ZSSWtlWmRmYklReW9...

if the name of the cookie starts from x-ms- then this cookie should be added as 
a header, otherwise as a cookie, please, see attached example:

if (_wcsnicmp(tokens[i].name, L"x-ms-", _countof(L"x-ms-")) == 
0)
{
std::wcout << "Add as a header: \n\t" << tokens[i].name << 
": " << tokens[i].data << std::endl;
}
else
{
std::wcout << "Add as a cookie: \n\t" << tokens[i].name << 
"==" << tokens[i].data << tokens[i].p3pHeader << std::endl;
std::wcout << "\tP3P: " << tokens[i].p3pHeader << std::endl;
std::wcout << "\tdwFlags for InternetSetCookieEx: "<< 
std::hex << tokens[i].flags<< std::endl;
// 
https://docs.microsoft.com/en-us/windows/win32/api/wininet/nf-wininet-internetsetcookieexa
}

Thank you,
Sasha

From: Ryan Sleevi rsle...@chromium.org
Sent: Tuesday, October 19, 2021 10:00 PM
To: Sasha Tokarev alex...@microsoft.com
Cc: z...@chromium.org; 
rsle...@chromium.org; 
blink-dev@chromium.org; 
g...@chromium.org; 
mme...@chromium.org; 
a...@chromium.org; 
yhir...@chromium.org; 
pastarm...@chromium.org
Subject: Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome



On Tue, Oct 19, 2021 at 9:41 PM Sasha Tokarev 
mailto: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)

[blink-dev] Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome

[Ryan Sleevi]

On Tue, Oct 19, 2021 at 9:41 PM Sasha Tokarev  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)

.

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.

[blink-dev] Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome

[Owen Min]

+Yulian Pastarmov 

On Sun, Sep 26, 2021 at 11:34 AM Ryan Sleevi  wrote:

> 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
> ,
> 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 , 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
> .
> It appears these providers may be device-wide (although only Microsoft
> IdPs
> 
> are supported for that), but are primarily user-wide. If I'm understanding
> correctly, any IdP application can register to be the handler
> 
> 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
> 
> is easier than GINA
> ,
> but not by much, and SSP/APs
> 
> aren't fun to write, and it seems like this is the next evolution in this
> space, ignoring ADAL/MSAL
> 
> :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
> ,
> 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
> .
> 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 

[blink-dev] Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome

[Ryan Sleevi]

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
,
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 , 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
.
It appears these providers may be device-wide (although only Microsoft IdPs

are supported for that), but are primarily user-wide. If I'm understanding
correctly, any IdP application can register to be the handler

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

is easier than GINA
,
but not by much, and SSP/APs

aren't fun to write, and it seems like this is the next evolution in this
space, ignoring ADAL/MSAL

: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
,
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
.
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 

[blink-dev] RE: [EXTERNAL] Re: Native support of Windows SSO in Chrome

['Sasha Tokarev' via blink-dev]

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 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
 (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.
 *   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 pro

[blink-dev] Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome

[Matt Menke]

Thanks for the details, Sasha!  Please don't feel like you need to answer
my questions while on vacation - there's no rush here.

Enjoy your vacation!

On Sat, Sep 25, 2021 at 9:22 PM Sasha Tokarev  wrote:

> Hi Matt,
>
>
>
> Disclaimer: I’m at vacation my responses may delay.
>
>
>
> *> What's the flow to join a cloud identity here?  What are the permission
> prompts like?  I assume that home users who use generic home user Microsoft
> accounts (as I believe encouraged during Windows install/configuration)
> aren't assumed to be granting this permission, though it could reasonably
> be described as a "device joined to cloud identity"?*
>
>
>
> There are many ways of joining devices, many of them looks like domain
> joining, and requires admin’s action and explicit user action. Home user
> also either go via explicit action and consent which include web SSO:
>
> [image: Graphical user interface, text, application Description
> automatically generated]
>

Thanks!  So this is a per-local-app permission, that can also be granted to
all apps?  My main concerns, in terms of privacy (not security issues) here
are:

1)  Home user using a Microsoft account on their personal device
unexpectedly gets logged in.  If the user has to give explicit permission
to Chrome or all apps (apart from just using a Microsoft account), as it
sounds like is the case, I'm much less concerned about this.  I'd still be
more comfortable if Chrome-side integration is disabled by default, though
the settings folk may not think it's worth a new setting.
2)  An enterprise uses corp Microsoft accounts, but doesn't want to use
Microsoft as an IDP.  It may not want this information to be sent to
Microsoft.  Admittedly, I'm not sure how much of a concern this is, if
Microsoft is managing their accounts in the first place.  Note that I'd be
concerned about this happening for non-Microsoft managed accounts here,
too, just think it's less likely for it to be possible to accidentally
happen for non-Microsoft accounts.  Sounds like this does need explicit
opt-in even with Microsoft managed accounts, so sounds like this isn't at
all an issue.
3)  A bit less of a concern, but a person using their home account on a
corp device (not uncommon, though not generally a great idea), gets their
personal, non-corp managed account, sent to the IDP, inheriting the fact
that IDP is enabled on the device.  It could either be using the corp IDP
configuration, or the IDP configuration associated with the domain of their
home account - both seem problematic to me.
4)  Enterprise intends to use the feature, but accidentally leaks this
information to a 3P. bouncing through the IDP.  It sounds like there's
server-side configuration to prevent this, and given that the feature has
to be explicitly enabled on the OS, they've already indicated that they
trust their IDP.

 *> Would this be enabled by default (for enterprise users only)? *
>
>
>
> It is like domain join, when you join device to domain you expect SSO.
> Given that there is explicit user or admin action, and consent, which
> includes web SSO, it should be enabled by default both for consumers and
> enterprise users, like it is enabled in Edge. Additional flags will only
> complicate deployment and doesn’t bring extra protection, users will have
> to remember about the extra flag. It decreases effectiveness of the
> feature.
>
>
>
> We do not ask to deploy extra flags to enable Windows Integrated Auth,
> once you joined to the domain you got it, this is a new versions of Windows
> Integrated Authentication.
>
>
>
> *> Also, what about incognito? *
>
>
>
> In incognito it must be OFF by default, to protect user and organization,
> but it is OK, to have a settings controllable by admin to make it on.
>
>
>
> *> So this means evil.com
> 
> could redirect to https://login.microsoftonline.com/
> ,
> and tell it to log in using the IDP to https://www.mywork.com
> 

[blink-dev] RE: [EXTERNAL] Re: Native support of Windows SSO in Chrome

['Sasha Tokarev' via blink-dev]

Hi Matt,

Disclaimer: I'm at vacation my responses may delay.

> What's the flow to join a cloud identity here?  What are the permission 
> prompts like?  I assume that home users who use generic home user Microsoft 
> accounts (as I believe encouraged during Windows install/configuration) 
> aren't assumed to be granting this permission, though it could reasonably be 
> described as a "device joined to cloud identity"?

There are many ways of joining devices, many of them looks like domain joining, 
and requires admin's action and explicit user action. Home user also either go 
via explicit action and consent which include web SSO:
[Graphical user interface, text, application  Description automatically 
generated]

> Would this be enabled by default (for enterprise users only)?

It is like domain join, when you join device to domain you expect SSO. Given 
that there is explicit user or admin action, and consent, which includes web 
SSO, it should be enabled by default both for consumers and enterprise users, 
like it is enabled in Edge. Additional flags will only complicate deployment 
and doesn't bring extra protection, users will have to remember about the extra 
flag. It decreases effectiveness of the feature.

We do not ask to deploy extra flags to enable Windows Integrated Auth, once you 
joined to the domain you got it, this is a new versions of Windows Integrated 
Authentication.

> Also, what about incognito?

In incognito it must be OFF by default, to protect user and organization, but 
it is OK, to have a settings controllable by admin to make it on.

> So this means 
> evil.com
>  could redirect to 
> https://login.microsoftonline.com/,
>  and tell it to log in using the IDP to 
> https://www.mywork.com,
>  by providing a redirect URI there?  Or is the referrer to the IDP validated 
> in some way?

I'm not sure I fully understand the attack here. Evil.com will have to use 
mywork.com's redirect URI, it means that token 
(authentication artifact) will be delivered to https://www.mywork.com not to 
evil.com. Overall, these kinds of threats covered by federation protocols OIDC, 
OAuth, SAML etc. IDPs exist in the modern world (Facebook, Google, AAD, MSA) 
they have to be protected from all kinds of threats, as they authenticate the 
user and redirect the token. All these IDPs produce a cookie for themselves to 
avoid useless re-auth. This proposal only manages the way of more secure 
delivering those cookies from native component in OS, which must be implemented 
by IDPs vendors, to IDPs web site. This proposal doesn't change protocols how 
an IDP talks with web applications (aka resources, aka target resources, aka 
relying parties). All threats and mitigation applied to existing protocols.

> I believe the initial proposed CL I saw wiring this up added the cookies to 
> all requests to the magic URL. Does this mean that only main frame 
> navigations need these additional cookies?

No, all navigations. It is a cookie by nature, it must follow all cookie rules. 
If XHR-web request should append a cookies, then we need append this cookie. 
The difference between this cookie and regular cookie is regular cookie is not 
protected, an attacker can steal it and use on a different device. This cookie 
is protected. Attacker can steal it but it will be expired very fast.

> Is there some other communication behind the scene between the OS and the IDP 
> here to authenticate the device?  Or is this just a matter of encoding data 
> in the request?

I think it is easier to answer this question is to describe what cookie is. 
Please, note, format of the cookie is something internal between IDP native 
component and IDP web services.  Microsoft's cookie is JWT-blob that contains 
PRT