On 5 Sep 2024, at 05:45, David Waite <da...@alkaline-solutions.com> wrote: > > > >> On Sep 4, 2024, at 4:27 PM, Neil Madden <neil.e.mad...@gmail.com> wrote: >> >>> On 4 Sep 2024, at 22:48, Watson Ladd <watsonbl...@gmail.com> wrote: >>> >>> I can always grab the cookie jar off the user browser if I have that >>> level of access. >> >> USB access is not privileged, but that’s beside the point. > >> >> Put another way, the phishing-resistance of WebAuthn only really makes sense >> in a world of sandboxed apps: web apps, mobile apps. Any spec that >> encourages the use of OAuth auth flows outside of such sandboxed >> environments, as this one potentially does, is going to make defending >> against phishing harder. > > The client is not an identified/authenticated component in the architecture, > so there is a user trust required in using a client - that the client > actually is an agent acting in the user’s interest rather than acting > maliciously. > > Platforms have the ability to provide specific API for these interactions to > become a trustworthy client, and to block privileged access (including access > to speak directly to hardware) behind audited entitlements to prevent from > installed software acting as a malicious client.
Right, this is what I mean by sandboxed. > > Note that some platforms also provide entitlements and heuristics for > password manager access - however, as a knowledge-based system the platform > cannot really prevent malicious applications from still attempting to > manipulate their way to credential phishing. > >> >> (I’d also question why first-party apps need a standardised API for this >> anyway: they can do whatever they like using proprietary APIs already). > > I would struggle to come up with standards-track RFCs which would not be able > to instead be accomplished with proprietary APIs. The editors and working > groups found value in peer review and in interoperability. Standards are for promoting interoperability, not for getting free peer review of private APIs. > > I have seen the pitfalls of a proprietary approach to this and would say peer > review is important. My primary concern is whether we can have a clients that > authenticate against multiple implementing ASes based solely on this work. > Profiling authentication methods like passkey-based authentication would go a > long way toward alleviating that concern. > > -DW _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
