> I agree, I removed the mention of OIDC. If that means you'd leave the OAuth prohibition, it's still misleading or confusing. OIDC is of course an extension of or layer over OAuth. If you prohibit OAuth, you prohibit OIDC. You don't mean it that way, but that's the way it reads.
On Thu, Jul 25, 2019 at 12:51 PM Justin Richer <jric...@mit.edu> wrote: > I also think it would be useful, but a problem is that things like > “application type” are usually a stand in for a whole bunch of different > attributes that we actually care about. That’s what happened with > web/native and why, to my knowledge, nobody really uses those in lieu of > things like public/confidential and redirect URI locations instead for > policy decisions. If we do enumerate these, we would also need to enumerate > all of the things it means. > > I tried to shy away from “application type” style switches in XYZ’s straw > man, and instead opt for recipes of applying the different options to > different kinds of clients. I don’t know how long that will hold up though. > > — Justin > > On Jul 25, 2019, at 8:11 AM, Filip Skokan <panva...@gmail.com> wrote: > > Obviously it can do it on a per-client basis still, but now an AS is going >> to have to know a bit more about the app itself. Perhaps we finally need a >> few more entries in the “application_type” metadata parameter from OIDC’s >> extension RFC7591 beyond “native” and “web”? But we at least probably want >> to point out to AS implementors that this is something they want to >> consider tracking in their data model for clients. >> > > I would very much like to see that. native/web possibly in combination > with token_endpoint_auth_method and the client being DCR or "static" is far > from being enough to make a policy decision. > > S pozdravem, > *Filip Skokan* > > > On Thu, 25 Jul 2019 at 13:45, Justin Richer <jric...@mit.edu> wrote: > >> This raises an interesting question that I don’t think we’ve addressed >> yet: how to appropriately vary token lifetimes and access for different >> clients. >> >> Previously, an AS could see that a client was using the implicit flow and >> decide to limit token lifetimes or scopes based on that alone. Similarly, I >> know of at least some AS implementations that let you limit what scopes you >> allow under the client credentials grant. The key issue is that if all your >> clients are using the auth code flow (which I agree they should), then how >> does an AS tell the difference in capabilities between incoming clients? >> >> Obviously it can do it on a per-client basis still, but now an AS is >> going to have to know a bit more about the app itself. Perhaps we finally >> need a few more entries in the “application_type” metadata parameter from >> OIDC’s extension RFC7591 beyond “native” and “web”? But we at least >> probably want to point out to AS implementors that this is something they >> want to consider tracking in their data model for clients. >> >> — Justin >> >> On Jul 25, 2019, at 4:04 AM, David Waite <da...@alkaline-solutions.com> >> wrote: >> >> >> >> >> On Jul 24, 2019, at 3:03 PM, Aaron Parecki <aa...@parecki.com> wrote: >> >> On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier >> <dba...@leastprivilege.com> wrote: >> >> <snip> >> >> I would rather say that ANY JS app should use CSP to lock down the >> browser features to a minimal attack surface. In addition, if refresh or >> access tokens are involved - further settings like disabling inline >> scripting (unsafe inline) and eval should be disabled. >> >> >> I'm not sure what to do with this suggestion. It feels like a blanket >> recommendation of enabling CSP will likely be ignored since it's too >> broad, and recommending disabling inline scripts is overreaching >> unless backed up by a specific threat it's protecting against. Did you >> have a particular threat in mind? >> >> >> I would say that browser applications should take measures to harden >> their applications again code injection and arbitrary code execution. >> Examples include eliminating inline script (and limiting embeddable objects >> as much as possible) via CSP, and versioning third party resources via >> techniques like subresource integrity. Mechanisms such as augmenting the >> codebase to make sure all appropriate user input, data storage, and output >> properly sanitize data may be used - although they may be more expensive to >> implement and audit. >> >> The AS should likewise take into account an application’s overall >> security posture when deciding appropriate policies around delegated >> authorization scopes and token lifetimes. >> >> Best current practices include turning the screws tightly around CSP. But >> it is (theoretically) possible to accomplish the same with brute-force >> sanitization, which has been made simpler with framework support. It is >> still ultimately the AS job to decide which clients have which capabilities. >> >> -DW >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
