IMO, we're getting very off topic here. The WebAuthn text is not part of the draft being called for adoption.
On Thu, Sep 5, 2024 at 2:15 AM Neil Madden <neil.e.mad...@gmail.com> wrote: > 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 >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
