Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

> Am 24.07.2019 um 09:50 schrieb Tomek Stojecki > : > > I agree that 6.1 takes too broad of a swipe, but I'd say with same-site > cookies and (sadly) without token-binding, the suggestion to use cookie based > session following oauth/oidc auth is a good one and should be incorporated > perha

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

> Am 24.07.2019 um 04:13 schrieb David Waite : > > Perhaps it should be turned into a stated document assumption (that the > reader has decided to use OAuth) rather than guidance later in the document > (that OAuth may not be the best fit) +1 smime.p7s Description: S/MIME cryptographic signa

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

Am 24.07.2019 um 22:13 schrieb Aaron Parecki : >> 2) Regarding architectures: I think this BCP should focus on recommendations >> for securely implementing OAuth in the different potential architecture. I >> don’t think we should get into the business of recommending and assessing >> other so

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

*whew* this is a lot of feedback. I will try to address all of these points in this thread. On Mon, Jul 22, 2019 at 9:30 AM Torsten Lodderstedt wrote: 1) This BCP should not be limited to public clients. Your BCP itself > already describes an architecture where the OAuth client is a backend that

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

I agree that 6.1 takes too broad of a swipe, but I'd say with same-site cookies and (sadly) without token-binding, the suggestion to use cookie based session following oauth/oidc auth is a good one and should be incorporated perhaps in 6.2? Leo sums it up well here: > We need to be clear on the

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

> On Jul 23, 2019, at 12:47 PM, Brian Campbell > wrote: > > > > On Mon, Jul 22, 2019 at 7:31 AM Torsten Lodderstedt > wrote: > > 2) Regarding architectures: I think this BCP should focus on recommendations > for securely implementing OAuth in the different

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

On Mon, Jul 22, 2019 at 7:31 AM Torsten Lodderstedt wrote: > > 2) Regarding architectures: I think this BCP should focus on > recommendations for securely implementing OAuth in the different potential > architecture. I don’t think we should get into the business of recommending > and assessing ot

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

I agree that there's a problem regarding the scope of this BCP . Or at least, I'm confused. Is this BCP supposed to be all about the architecture where the browser holds the token(s)? If so, then a) let's just put that out front and center: that's the context of this BCP. That's what's meant by

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

Hi Aaron, thanks for your continued work on the topic. Here are some general remarks on the current revision: 1) This BCP should not be limited to public clients. Your BCP itself already describes an architecture where the OAuth client is a backend that may be a confidential client (see sec

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

> > Isn't this recommendation neglecting some benefits or use cases of > Oauth? This recommendation doesn't say you can't still centralize your account management in a dedicated component. If that component shares a domain with the application, you don't need OAuth to hop back and forth, you can

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

Hi, A few rewording suggestions; *section-6.2* Original: The Application Server SHOULD use the OAuth 2.0 authorization code grant to initiate a request *request *for an access token... Suggestion: The Application Server SHOULD use the OAuth 2.0 authorization code grant to initiate a request for

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

I see now that my arguments for softening the 6.1 language are backed and expanded on by the last paragraph of section 5, starting with " By redirecting to the authorization server,..." On Mon, Jul 8, 2019 at 8:44 PM Leo Tohill wrote: > regarding 6.1. Apps Served from a Common Domain as the Re

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

(should I start a new thread instead of making multiple replies to this message?) Re: Sec Typo/grammar in: "First- party apps are applications where by the same organization that provides the API being accessed by the application." Suggested rewrite: "First- party apps are applications where the

Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

regarding 6.1. Apps Served from a Common Domain as the Resource Server Isn't this recommendation neglecting some benefits or use cases of Oauth? * An application that doesn't collect user credentials is an app that doesn't need to be audited for problems such as password leakage into log files.

[OAUTH-WG] New OAuth for Browser-Based Apps draft -02

Hi all, I've just uploaded a new version of oauth-browser-based-apps in preparation for the meeting in Montreal. https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02 This draft incorporates much of the feedback I've received over the last couple months, as well as what we discussed