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

[Watson Ladd <[e-mail]>]

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.

>
>
> — Neil
>
> So, long story short, yes.
>
> On Wed, Sep 4, 2024 at 12:41 PM Neil Madden <[e-mail]> wrote:
>>
>>
>>
>> On 4 Sep 2024, at 17:09, Aaron Parecki <[e-mail]> wrote:
>>
>> 
>> A native UI does not rule out WebAuthn/FIDO, in fact we have an in-progress branch of the draft that shows how you could support passkeys with this spec: https://github.com/aaronpk/oauth-first-party-apps/pull/93
>>
>>
>> Thanks, that’s good to know. Does it preserve phishing resistance? Ie the app cannot spoof the rpId?
>>
>>
>> While there isn't an RFC for authenticating first-party apps, there is plenty of precedent for doing so already using the Apple and Android APIs. There is an adopted in-progress draft that could standardize this as well: https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/
>>
>>
>> Also good to know. Is the intent to restrict the draft to just mobile apps (and ones with secure enclaves?), or also desktop?
>>
>> I’d be a lot more comfortable with the draft if this SHOULD in section 1.1 became a MUST:
>>
>> “ This specification MUST NOT be used by third party applications, and the authorization server SHOULD take measures to prevent use by third party applications. (e.g. only enable this grant for certain client IDs, and take measures to authenticate first-party apps when possible.)”
>>
>> — Neil
>>
>>
>> Aaron
>>
>> On Wed, Sep 4, 2024 at 7:37 AM Neil Madden <[e-mail]> wrote:
>>>
>>> I am a bit skeptical about this one. I’m not convinced we should be recommending native UI until/unless we have a really good story around authenticating first-party apps. Without such a story, I don’t think this should be adopted. Unless I’m mistaken, a native UI also rules out WebAuthn/FIDO-based authenticators? We should not be adopting drafts that increase phishing risks for the sake of aesthetics.
>>>
>>> — Neil
>>>
>>> On 3 Sep 2024, at 11:46, Rifaat Shekh-Yusef <[e-mail]> wrote:
>>>
>>> All,
>>>
>>> As per the discussion in Vancouver, this is a call for adoption for the First Party Apps draft:
>>> https://datatracker.ietf.org/doc/draft-parecki-oauth-first-party-apps/
>>>
>>> Please, reply on the mailing list and let us know if you are in favor or against adopting this draft as WG document, by Sep 17th.
>>>
>>> Regards,
>>>  Rifaat & Hannes
>>> _______________________________________________
>>> OAuth mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
>> OAuth mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]



-- 
Astra mortemque praestare gradatim