[OAUTH-WG] Re: Call for adoption - First Party Apps

[Tim Cappalli <[e-mail]>]

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 <[e-mail]> wrote:

> On 5 Sep 2024, at 05:45, David Waite <[e-mail]> wrote:
> >
> > 
> >
> >> On Sep 4, 2024, at 4:27 PM, Neil Madden <[e-mail]>
> wrote:
> >>
> >>> On 4 Sep 2024, at 22:48, Watson Ladd <[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>