On Wed, Nov 7, 2018 at 7:20 AM Joseph Heenan <jos...@authlete.com> wrote:


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

That's a great point, thanks. I've removed the reference to native apps
being public clients since it doesn't really add anything to this spec if I
have to caveat the description.

On Thu, Nov 15, 2018 at 12:58 PM Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

> > First of all the AS decides whether it issues refresh tokens or not.
> Having the ability does not mean the AS must do it. If you feel it’s safer
> to not do it. Fine.
> > Sure, and this should be mentioned then somewhere (either in the threats
> doc or in this proposed best practice doc). Not all end developers using
> these protocols fully understand the ramifications.
> @Aaron: I suggest this goes to the SPA BCP since this is client specific.


Thanks, I agree that this document should include some recommendations
around refresh token handling. Looking at the discussion in this thread, it
seems there are a few different strategies folks are taking. Since it seems
like there isn't a strong consensus, it sounds like this would be better
suited for the "Security Considerations" section, and to not make
MUST/SHOULD recommendations, but rather just point out the issues. Any
thoughts on that before I take a stab at writing something?

I've incorporated some of the other feedback here and published an updated
version:

https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-01

Thanks for the feedback so far.

---
Aaron Parecki
https://aaronparecki.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to