Y'all are missing another option. (re Sam's Comments) The user is given a user agent to use on their own device when accessing enterprise data. I know of two that are shipping today. https://www.getprimary.com/ Now it is possible to access other sites with these browsers as well - in fact they specifically support sites like github in such a way to get enterprise creds. Perhaps we need to test these mechanisms with those user agents? Is it helpful if i asked them for feedback - when this gets to blink they will see them then as they are chromium forks. That might cause them to change the FedCM code.
Interested in the problem of multiple IdPs. I run three different browsers now just to deal with that problem. Relying parties accept different IdP????? that sux. I want to decide who I am based on the circumstances!!!!!! ..tom On Wed, May 8, 2024 at 2:02 PM Sam Goto <goto=40google....@dmarc.ietf.org> wrote: > > > On Wed, May 8, 2024 at 2:01 PM Joseph Heenan <jos...@authlete.com> wrote: > >> >> >> On 8 May 2024, at 21:43, Sam Goto <g...@google.com> wrote: >> >> >> >> On Wed, May 8, 2024 at 1:34 PM Joseph Heenan <jos...@authlete.com> wrote: >> >>> Hi Neil >>> >>> >>> On 8 May 2024, at 18:45, Neil Madden <neil.e.mad...@gmail.com> wrote: >>> >>> >>> On 8 May 2024, at 17:52, Sam Goto <g...@google.com> wrote: >>> >>> On Wed, May 8, 2024 at 7:23 AM Neil Madden <neil.e.mad...@gmail.com> >>> wrote: >>> >>> >>> >>> >>>> In particular, the call to the accounts endpoint assumes that the IdP >>>> is willing to provide PII about the user to the browser. That seems >>>> questionable. >>>> >>> >>> Aside from a privacy/security threat model perspective (meaning, the >>> user agent already has visibility over every network request made available >>> to the content area) >>> >>> >>> Sure, but if I use the recommended auth code flow or encrypted ID >>> tokens, then PII is not exposed to the browser. And it’s not just the >>> browser itself in the current proposal, as the token is exposed to >>> javascript, of course, so the usual XSS risks. >>> >>> >>> Sam’s response here is fair, but also note that as far as I understand >>> it you can still use the authorization code flow or encrypted id tokens >>> with the FedCM API >>> >> >> That's correct: the browser doesn't open the response from the IdP to the >> RP, so it can, for example, be encrypted. >> >> I was assuming that Neil was referring to the fact that the >> id_assertion_endpoint (which contains the user's IdP's PII accounts >> <https://fedidcg.github.io/FedCM/#dictdef-identityprovideraccount>) >> become, suddenly, transparent to the browser. >> >> >> Oh yes, that’s true - but (I think) the data from the >> id_assertion_endpoint at least isn’t exposed to javascript and isn’t >> vulnerable to XSS? >> > > That's correct. > > >> >> Joseph >> >> _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
