On Wed, May 8, 2024 at 3:10 PM Tom Jones <thomasclinganjo...@gmail.com> wrote:
> 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!!!!!! > That's quite interesting! Can you expand on this a bit more? > > ..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 >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
