Often a user needs to be presented with a prompt collecting some data to
identity the upstream IdP (e.g. email, or something else). This is very common
with B2B relationships. This is in lieu of showing a long list of the IdP
(NASCAR) buttons because perhaps you, as a business, don't want to show off all
the business partners you integrate with for SSO.
Hope that makes sense.
-Brock
On 5/9/2024 12:04:13 PM, Dick Hardt <dick.ha...@gmail.com> wrote:
Would you elaborate on your point Brock? I don’t follow.
On Thu, May 9, 2024 at 8:54 AM Brock Allen <brockal...@gmail.com
[mailto:brockal...@gmail.com]> wrote:
This is why redirects with a custom UI are so essential. This allows other
forms of HRD without a NASCAR button list too. I hope that this will remain
possible, as it's crucial to so many business use cases.
-Brock
On 5/9/2024 11:06:23 AM, Dick Hardt <dick.ha...@gmail.com
[mailto:dick.ha...@gmail.com]> wrote:
The NASCAR problem is rooted in the RP does not know which provider(s) the user
has, so sites showed all the choices. FedCM only shows the provider(s) the user
has.
On Thu, May 9, 2024 at 5:33 AM Warren Parad <wparad=40rhosys...@dmarc.ietf.org
[mailto:40rhosys...@dmarc.ietf.org]> wrote:
I think I'm still missing something, and I'm sure it was discussed somewhere
and I just didn't see it. How will this help avoid the NASCAR problem, for
sites when a user signs up or when the user signs in on a new browser?
On Thu, May 9, 2024 at 1:07 AM Sam Goto <goto=40google....@dmarc.ietf.org
[mailto:40google....@dmarc.ietf.org]> wrote:
On Wed, May 8, 2024 at 3:50 PM Neil Madden <neil.e.mad...@gmail.com
[mailto:neil.e.mad...@gmail.com]> wrote:
On 8 May 2024, at 22:01, Joseph Heenan <jos...@authlete.com
[mailto:jos...@authlete.com]> wrote:
On 8 May 2024, at 21:43, Sam Goto <g...@google.com [mailto:g...@google.com]>
wrote:
On Wed, May 8, 2024 at 1:34 PM Joseph Heenan <jos...@authlete.com
[mailto:jos...@authlete.com]> wrote:
Hi Neil
On 8 May 2024, at 18:45, Neil Madden <neil.e.mad...@gmail.com
[mailto:neil.e.mad...@gmail.com]> wrote:
On 8 May 2024, at 17:52, Sam Goto <g...@google.com [mailto:g...@google.com]>
wrote:
On Wed, May 8, 2024 at 7:23 AM Neil Madden <neil.e.mad...@gmail.com
[mailto: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 depends on whether the IdP correctly enforces the presence of the
sec-fetch-dest header. If it doesn’t then yes, it would be vulnerable.
Presumably it’s also vulnerable on older/niche browsers that don’t block sec-*
headers: caniuse.com [http://caniuse.com] reckons > 8% of users globally are
using browsers that don’t understand any sec-fetch-* headers. I’m not sure when
sec-* was added to the forbidden list.
I guess, flipping this around, we might ask what is the legitimate purpose for
which browsers need to access the user’s name, email address (both requires)
and other identifying information? I’d have thought an identifier (possibly
randomised) and some user-supplied account nickname would be sufficient.
That's easier to answer: the browser needs name/email/picture to construct an
account chooser
[https://docs.google.com/presentation/d/1iURrPakaHgBfQ6mAefKijjxToiTTgBSPz1rtaV0od98/edit#slide=id.p],
which is the UX that tested best with users by a far margin.
Static/unpersonalized permission prompts - example
[https://www.cookiestatus.com/images/content/storage-access-api.jpg] in Safari,
example
[https://developers.google.com/static/privacy-sandbox/assets/images/storage-access-api-permission-prompt.png]
in Chrome - perform extremely poorly (in comparison to account choosers),
although have other benefits too (namely ergonomics and extensibility), so
Chrome (and others) expose that too in the form of the Storage Access API
[https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API].
— Neil
_______________________________________________
OAuth mailing list -- oauth@ietf.org [mailto:oauth@ietf.org]
To unsubscribe send an email to oauth-le...@ietf.org
[mailto:oauth-le...@ietf.org]
_______________________________________________
OAuth mailing list -- oauth@ietf.org [mailto:oauth@ietf.org]
To unsubscribe send an email to oauth-le...@ietf.org
[mailto:oauth-le...@ietf.org]
_______________________________________________ OAuth mailing list --
oauth@ietf.org [mailto:oauth@ietf.org] To unsubscribe send an email to
oauth-le...@ietf.org [mailto:oauth-le...@ietf.org]
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
![https://www.cookiestatus.com/images/content/storage-access-api.jpg] in](https://www.cookiestatus.com/images/content/storage-access-api.jpg] in){kind=link}
