I agree with you that how we a 1P AS authenticates the user needs to be carefully examined. You may be correct that how it is done needs to be revised.
My point is that many deployments are 1P deployments, and the protocol can be simpler for those use cases, which is the objective of the draft from my perspective. I think we should work on developing a best practice for 1P deployments. Do you not agree with that? We can argue over how to do it later. On Tue, Sep 10, 2024 at 11:59 AM Neil Madden <neil.e.mad...@gmail.com> wrote: > I know that apps that accept credentials directly are common place. But > the direction of travel has so far been to discourage that: eg deprecating > ROPC, requiring use of an external vs embedded user-agent etc. (Sorry, I > misremembered: it’s BCP 212 that requires this, not the security BCP — and > it has a lot of good rationale for that decision). > > 3rd party apps follow where first-party apps lead. > > — Neil > > On 10 Sep 2024, at 11:14, Dick Hardt <dick.ha...@gmail.com> wrote: > > > Neil > > Users input credentials directly into apps all the time in OAuth -- it is > at the AS. > > There are many deployments that use OAuth where the AS and RS are the same > party. The objective of this draft (as I understand it) is to provide a > simplified OAuth flow for this use case. The BCP does not address this use > case. > > Why would we not want to provide a best practice for deployments where the > AS and RS are the same party? We will likely improve the security of those > deployments over them making up their own protocol, won't we? > > /Dick > > > > On Tue, Sep 10, 2024 at 10:20 AM Neil Madden <neil.e.mad...@gmail.com> > wrote: > >> The draft is motivated by allowing native apps to provide a login journey >> for OAuth rather than using the browser. This encourages people to input >> credentials directly into apps, which (a) directly contradicts the advice >> in the security BCP, and (b) opens up users to significantly more attack >> vectors (including that the phishing-resistance of FIDO is significantly >> weakened). We shouldn’t be encouraging this. >> >> — Neil >> >> On 5 Sep 2024, at 15:48, Tim Cappalli <tim.cappa...@okta.com> wrote: >> >> >> 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 >> >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
