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

[Neil Madden <[e-mail]>]

On 4 Sep 2024, at 22:48, Watson Ladd <[e-mail]> wrote:
> 
> On Wed, Sep 4, 2024 at 2:46 PM Neil Madden <[e-mail]> wrote:
>> 
>> 
>> 
>> On 4 Sep 2024, at 21:31, Tim Cappalli <[e-mail]> wrote:
>> 
>> 
>>> 
>>> Thanks, that’s good to know. Does it preserve phishing resistance? Ie the app cannot spoof the rpId?
>> 
>> 
>> The WebAuthn client for native apps is the app platform. The app platform, aka the OS, handles origin binding using existing app to web domain association methods (Android Asset Links, Apple Associated Domains) . This is used for both embedded WebViews and native app platform APIs. For System WebView, the WebAuthn client is the web platform, just like a browser (WebView details: Android, iOS, macOS).
>> 
>> 
>> I can see how that works for iOS and Android, where apps are sandboxed. But can’t a macos/Windows/Linux app bypass the “official” WebAuthn API and just talk CTAP directly to a USB authenticator? (You used to even be able to do this from the browser: https://www.yubico.com/support/security-advisories/ysa-2018-02/)
>> 
>> Or is the intent to limit the spec to sandboxed apps? (If so, some kind of attestation to ensure the app actually is sandboxed seems a good idea).
> 
> 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. 

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

— Neil