It's an interesting topic. I think there is a definitely a set of options and considerations for this. Namely operational. For example, hugely popular mobile apps (multi-million downloads across different OS's) using dynamic reg with per-instance private creds requires the AS to be able to store and index those client profiles easily. Smaller scale custom built authorization servers are not necessarily going to be able to handle that - hence the popularity of assuming everything is generic and public coupled with PKCE.
On the other hand, if a less popular first-party app used internally for employees for example, might well go for secure element integration on the appropriate mobile OS. So, I guess options are needed and best practice for a few subtly different scenarios. Regards Simon On 07/11/18 15:20, Joseph Heenan wrote: > Hi Aaron, > > Thanks for putting this document together, I think this kind of > guidance is invaluable. > > It may be worth slightly rewording 7.2 as it may encourage a growing > misconception that all native apps must be public clients. With many > devices now having embedded HSMs, we’ve seen increasing interest in > mobile apps being dynamically (per-install) registered oauth2 private > clients, and that model has a lot of advantages. (I’m not sure if we > might see a similar model evolving for web apps.) > > The BCP for native apps does allow > this:https://tools.ietf.org/html/rfc8252#section-8.4 > > Cheers, > > Joseph > > > > > >> On 6 Nov 2018, at 10:13, Aaron Parecki <aa...@parecki.com >> <mailto:aa...@parecki.com>> wrote: >> >> Thanks Hannes, >> >> Since I wasn't able to give an intro during the meeting today, I'd >> like to share a little more context about this here as well. >> >> At the Internet Identity Workshop in Mountain View last week, I led a >> session to collect feedback on recommendations for OAuth for browser >> based apps. During the session, we came up with a list of several >> points based on the collective experience of the attendees. I then >> tried to address all those points in this draft. >> >> The goal of this is not to specify any new behavior, but rather to >> limit the possibilities that the existing OAuth specs provide, to >> ensure a secure implementation in browser based apps. >> >> Thanks in advance for your review and feedback! >> >> Aaron Parecki >> aaronpk.com <http://aaronpk.com/> >> >> >> >> On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig >> <hannes.tschofe...@arm.com <mailto:hannes.tschofe...@arm.com>> wrote: >> >> Hi all, >> >> Today we were not able to talk about >> draft-parecki-oauth-browser-based-apps-00, which describes >> "OAuth 2.0 for Browser-Based Apps". >> >> Aaron put a few slides together, which can be found here: >> >> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf >> >> Your review of this new draft is highly appreciated. >> >> Ciao >> Hannes >> IMPORTANT NOTICE: The contents of this email and any attachments >> are confidential and may also be privileged. If you are not the >> intended recipient, please notify the sender immediately and do >> not disclose the contents to any other person, use it for any >> purpose, or store or copy the information in any medium. Thank you. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> >> -- >> ---- >> Aaron Parecki >> aaronparecki.com <http://aaronparecki.com/> >> @aaronpk <http://twitter.com/aaronpk> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- ForgeRock <https://www.forgerock.com/> *Simon Moffatt* Technical Director Product Management | ForgeRock *t* (44) 7903 347 240 | *e* simon.moff...@forgerock.com <mailto:simon.moff...@forgerock.com> *twitter* @simonmoffatt | *web* www.forgerock.com <https://www.forgerock.com/> NOTICE: This message, including any attachments, may contain confidential information. If you are not the intended recipient, please advise the sender immediately and destroy all copies of this message and any attachments. ForgeRock Ltd may monitor email traffic data and also the content of email transmitted over its network for security purposes. No employee or agent is authorized to conclude any binding agreement on behalf of ForgeRock Ltd by means of e-mail communication. ForgeRock Ltd is a limited company registered in England and Wales; its registered address is 60 Queen Square, Bristol, BS1 4JZ; and its registration number is 7227664.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
