Re: [OAUTH-WG] Review of OAuth 2.0 for Browser-Based Apps

Thank you for the thorough review! My responses and feedback is below. I've gone ahead and published a new draft based on this feedback so that the edits can be read in context. It is now available here: https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-05 I've made all "EDITORIAL"

[OAUTH-WG] Side meetings for IETF 107 Vancouver

I reserved a room for a side meeting immediately following our first session on Monday. I put down "OAuth 2.1" as the topic, because I assume we'll have a lot to talk about again after the first session, but any topic is welcome really. Our first official meeting slot is 1:30-3:30pm Monday, and

[OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 for Browser-Based Apps Authors : Aaron Parecki David Waite

[OAUTH-WG] RFC 8707 on Resource Indicators for OAuth 2.0

A new Request for Comments is now available in online RFC libraries. RFC 8707 Title: Resource Indicators for OAuth 2.0 Author: B. Campbell, J. Bradley, H. Tschofenig Status: Standards Track

[OAUTH-WG] RFC 8705 on OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens

A new Request for Comments is now available in online RFC libraries. RFC 8705 Title: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens Author: B. Campbell, J. Bradley,

[OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 107

Dear Rifaat Shekh-Yusef, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. oauth Session 1 (2:00 requested) Monday, 23 March 2020, Afternoon Session I 1330-1530 Room Name: Regency E size: 150

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

It looks like there is consensus to remove ROPC for a user -- but that the password grant is not a bad practice for service accounts. That leads to providing clarity on service accounts. 1) add service account grant to the OAuth 2.1 document 2) write an OAuth 2.1 extension for service account

Re: [OAUTH-WG] More product group review comments on the OAuth 2.0 for Browser-Based Apps spec

> 9.3. Client Impersonation > It is implied that consent granted to public client should not be recorded: >> Even when the user has previously approved an >> authorization request for a given client_id, the request SHOULD be >> processed as if no previous request had been approved, unless the

Re: [OAUTH-WG] OAuth 2.1 - drop implicit flow?

I'm looking to close out this topic. I heard that Brian and Vittorio shared some points of view in the office hours, and wanted to confirm: + Remove implicit flow from OAuth 2.1 and continue to highlight that grant types are an extension mechanism. For example, if OpenID Connect were to be

Re: [OAUTH-WG] PKCE and refresh tokens

Hi Albin, Are you writing both the client and the server or writing client code to auth against a standard server? Unless you are writing the auth server code, using a library would be the best way to simplify. Thanks Naveen On Fri, Feb 28, 2020 at 7:48 AM Albin Nilsson wrote: > Hello, > >

Re: [OAUTH-WG] PKCE and refresh tokens

> On Feb 28, 2020, at 8:46 AM, Albin Nilsson wrote: > > Hello, > > I'm having some trouble with oauth and the Authorization Code flow and PKCE. > How can I get a refresh token? The refresh token flow requires a > client_secret, but PKCE prohibits client_secret. Is refresh token a no go?

Re: [OAUTH-WG] PKCE and refresh tokens

Hi Albin, It’s important to note that PKCE does explicitly prohibit client_secret, just offers a secure way of obtaining an access token when it’s impossible for a client_secret to be kept secret, as would be the case with a mobile application. The type of attack it prevents against is during the

[OAUTH-WG] PKCE and refresh tokens

Hello, I'm having some trouble with oauth and the Authorization Code flow and PKCE. How can I get a refresh token? The refresh token flow requires a client_secret, but PKCE prohibits client_secret. Is refresh token a no go? Kind regards, Albin ___

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

Hi, In additional to Bill's query, the use of the term "protected resource" in the context of RFC7662 is quite confusing. As defined by RFC6749 (which RFC7662 defers to for definition of the terms), the term "protected resource" is defined as an "access-restricted resource" that a client can

Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)

Hi Ben, > On 25. Feb 2020, at 23:52, Benjamin Kaduk via Datatracker > wrote: > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-oauth-jwt-introspection-response-08: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses

[OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

Hello, hopefully I am using the right email address. Simply put, can this spec be enhanced to clarify "Who can use the introspection endpoint for a refresh token? A resource provider or a client app or both?" RFC7662 clearly mentions that the user of introspection endpoint is a 'protected