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

[Tim Cappalli <[e-mail]>]

>
> 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
<https://developers.google.com/identity/credential-sharing/set-up>, Apple
Associated Domains
<https://developer.apple.com/documentation/xcode/supporting-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
<https://passkeys.dev/docs/reference/android/#webviews>, iOS
<https://passkeys.dev/docs/reference/ios/#webviews>, macOS
<https://passkeys.dev/docs/reference/macos/#webviews>).

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/
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/__;!!PwKahg!9rA-xLjriUl902lceiCiH6n9dEH_lrJR24HFJDPOKfVVmrh85ruqzBatSp5qEOCG1imuRFPrUerw6WixDMIB5LFQ$>
>
>
> 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/
>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-parecki-oauth-first-party-apps/__;!!PwKahg!9rA-xLjriUl902lceiCiH6n9dEH_lrJR24HFJDPOKfVVmrh85ruqzBatSp5qEOCG1imuRFPrUerw6WixDO9Lta0Z$>
>>
>> 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]
>