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