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

On Mon, Feb 24, 2020 at 6:49 AM Neil Madden wrote: > Well, kinda. People can still theoretically use OAuth 1 too, but the world > has moved on - software has dropped support for it, websites don’t support > it, and so on > I’m a bit confused about what OAuth 2.1 is intended to be. If it’s not

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-incremental-authz-01

On Wed, Sep 25, 2019 at 3:54 PM Brian Campbell wrote: > Just noticed that something is missing in > https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-02#section-5 > where it has just, "(Section 4.1.4 of )" > Thank you for catching this Brian. It was meant to read Section 4.1.4 of RF

Re: [OAUTH-WG] [Technical Errata Reported] RFC8252 (5848)

Process-wise I'm not sure if errata should be used to capture changing implementation details like this. We expected the implementation details that we documented in the appendix to change, and explicitly stated that assumption. "The implementation details herein are considered accurate at the time

Re: [OAUTH-WG] [Editorial Errata Reported] RFC8252 (5776)

This is an issue with the HTML auto generation, not the normative document. I believe this errata should be rejected. William On Fri, 5 Jul 2019 at 06:56, RFC Errata System wrote: > The following errata report has been submitted for RFC8252, > "OAuth 2.0 for Native Apps". > > --

Re: [OAUTH-WG] ID Token by Device Flow

Hi Taka, On Mon, Jun 24, 2019 at 12:16 PM Takahiko Kawasaki wrote: > Hi Justin, > > Thank you. Consensus will be that "openid" in the "scope" request > parameter should trigger generation of an ID token. > +1, and the last time I checked, that’s how Google's implementation behaved. I'm wonderi

Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (5708)

+1 to Justin Could this be handled in the extension spec potentially? Eg calling out that OAuth has that requirement, but documenting an extension-specific case that modifies it? William *From: *Justin Richer *Date: *Mon, May 13, 2019 at 11:06 AM *To: *RFC Errata System *Cc: *oauth@ietf.org I

Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-device-flow-13: (with COMMENT)

On Sat, Oct 27, 2018 at 4:11 PM Benjamin Kaduk wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-oauth-device-flow-13: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel f

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

On Wed, Nov 28, 2018 at 2:51 PM n-sakimura wrote: > That works. > > In fact, I would further go and say MUST NOT but that probably is too much > for a security consideration. > > Personally I think it's fine for a MUST NOT to appear in a security consideration section of a BCP. If you break it, t

Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security Topics -- Recommend authorization code instead of implicit

In BCP 212 we currently recommend against using implicit flow for native apps (Section 8.2), due to the inability to protect against interception with PKCE. AppAuth iOS & Android don't implement it, and the JS version didn't initially although it was requested by users who needed to do implicit aut

Re: [OAUTH-WG] Dynamic Client Registration with Native Apps

If the secret is dynamically provisioned then you have a confidential client. Anyone reverse engineering their own installation of the native app would only extract their own client's credentials, as opposed to the shared secret of all installations. Having a confidential client means that requests

Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-device-flow-11: (with DISCUSS and COMMENT)

Hi Benjamin, Thank you for your detailed review, and suggestions. Version 13 was just posted, and incorporates your suggestions and feedback. Replies inline: On Thu, Aug 2, 2018 at 5:21 PM, Benjamin Kaduk wrote: > On Wed, Aug 01, 2018 at 05:16:52PM -0700, William Denniss wrote: > >

Re: [OAUTH-WG] Remark on OAuth Device Flow Draft 12

Hi Dries, Good question. The intent of the expired_token error message is to communicate to the device client that it should stop polling as the session has expired. The reason we defined the separate error message for just this case was so that clients could present an accurate message (i.e. that

Re: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-device-flow-11: (with COMMENT)

Hi Ben, Thank you for your feedback. Version 12 has been posted which addresses some of your points. Replies inline: On Wed, Aug 1, 2018 at 2:36 PM, Ben Campbell wrote: > > -- > COMMENT: > --

Re: [OAUTH-WG] Opsdir last call review of draft-ietf-oauth-device-flow-10

Qin, Thank you for your valuable feedback. Version 12 incorporates some of your feedback. Replies inline: On Tue, Jun 12, 2018 at 4:25 AM, Qin Wu wrote: > Reviewer: Qin Wu > Review result: Ready > > I have reviewed this document as part of the Operational directorate¡¯s > ongoing > effort to re

Re: [OAUTH-WG] Alexey Melnikov's No Objection on draft-ietf-oauth-device-flow-11: (with COMMENT)

Alexey, Thank you for your feedback. Replies inline: On Sun, Jul 29, 2018 at 9:26 AM, Alexey Melnikov wrote: > > -- > COMMENT: > -- > > This is generally a fin

Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-device-flow-11: (with DISCUSS and COMMENT)

Benjamin, Thank you for the feedback. We just posted version 12 which addresses many of your feedback points. Replies inline. On Tue, Jul 24, 2018 at 6:31 AM, Benjamin Kaduk wrote: > > -- > DISCUSS: > --

Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

etf.org> wrote: > >> Microsoft’s Azure AD OAuth server has used the resource= parameter since >> at least 2012 to indicate what resource the requested access token is to be >> for. >> >> >> >> -- M

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-incremental-authz-00.txt

s it). Best, William > > Am 28.06.2018 um 22:14 schrieb internet-dra...@ietf.org: > > > > > > 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. >

Re: [OAUTH-WG] Last Call: (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard

On Thu, May 31, 2018 at 9:49 AM, Brian Campbell wrote: > > > On Wed, May 30, 2018 at 6:06 PM, William Denniss > wrote: > >> >> On Wed, May 30, 2018 at 3:48 PM, Brian Campbell < >> bcampb...@pingidentity.com> wrote: >> >>> I realize this is s

Re: [OAUTH-WG] Last Call: (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard

that endpoint. Do you have any proposed text to resolve this? > > On Wed, May 30, 2018 at 4:27 PM, William Denniss < > wdenniss=40google@dmarc.ietf.org> wrote: > > > Hi Andrew, > > > > On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras < > > andrewsc

Re: [OAUTH-WG] Publication has been requested for draft-ietf-oauth-device-flow-07

Thanks again for the feedback Scott. I've staged an update here: https://github.com/WilliamDenniss/draft-ietf-oauth-device-flow/pull/6 It expands on the brute force attack section to include some detail on this attack, as it is quite unique for OAuth brute-force attacks (since the victim actually

Re: [OAUTH-WG] Call for agenda items

Hannes & Rifaat, I would like the opportunity to present on OAuth 2.0 Incremental Authorization (draft-wdenniss-oauth-incremental-auth) [an update for which will be posted today] and "OAuth 2.0 Device Posture Signals" (draft-wdenniss-oauth-device-posture). I can also give an update on the status

Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices

On Fri, Dec 15, 2017 at 11:12 PM, Vladimir Dzhuvinov < vladi...@connect2id.com> wrote: > On 15/12/17 00:43, William Denniss wrote: > > On Fri, Dec 8, 2017 at 11:42 AM, Vladimir Dzhuvinov < > vladi...@connect2id.com > >> wrote: > >> Hi, > >>

Re: [OAUTH-WG] Token scanning attacks in RFC 7662

If you're interested in examples in the wild of token introspection without client authentication, Google offers one and specifically recommends that JS clients (which are public clients and thus can't use client authentication) use it to mitigate confused deputy attacks on access tokens. Documente

Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices (Brian Campbell)

This suggestion was considered by the working group, I raised the proposal at IETF98, you can see the recording . The WG rejected the inclusion of this construct in the device flow specification, but as Justin suggested, the door is open for a standalone doc

Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices

On Mon, Dec 11, 2017 at 8:46 AM, Brian Campbell wrote: > I couldn't get the QR code to work... ;) > Mild shock! ;-) > On Mon, Nov 27, 2017 at 6:55 AM, Rifaat Shekh-Yusef > wrote: > >> All, >> >> As discussed in Singapore, we are starting a WGLC for the >> *draft-ietf-oauth-device-flow-07* doc

Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices

On Fri, Dec 8, 2017 at 11:42 AM, Vladimir Dzhuvinov wrote: > Hi, > > I just got a question on Twitter about the slow_down error: > > https://tools.ietf.org/html/draft-ietf-oauth-device-flow-07#section-3.5 > > The question was why slow_down is communicated via HTTP status code 400 > and not 429 (T

Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)

Thanks Adam for your feedback, and reviewing the work in progress! v12 <https://tools.ietf.org/html/draft-ietf-oauth-native-apps-12> is out now with those and other IESG review related changes. On Fri, Jun 2, 2017 at 8:01 PM, Adam Roach wrote: > On 6/2/17 21:25, William Denniss wrote:

Re: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)

Thank you for your review. We've reworked section 8.7 to move the focus away from the user regarding mitigations for apps that fake external user-agents. On Tue, May 23, 2017 at 2:48 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-oauth-native-a

Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)

On Tue, May 23, 2017 at 9:53 AM, Adam Roach wrote: > On 5/23/17 05:09, Alexey Melnikov wrote: > > On Tue, May 23, 2017, at 10:24 AM, Alexey Melnikov wrote: > > Hi William, > > On 22 May 2017, at 23:14, William Denniss wrote: > > Section 8.1 makes the statement that

Re: [OAUTH-WG] [OPS-DIR] Opsdir telechat review of draft-ietf-oauth-native-apps-10

Thanks for your review Zitao! Version 12 addresses your comments. Detailed responses below: On Sun, May 21, 2017 at 8:05 PM, wangzitao wrote: > Reviewer: Zitao Wang (Michael) > > Review result: Has Nits > > > > I have reviewed this document as part of the Operational > directorate’s ongoing eff

Re: [OAUTH-WG] Call for Adoption: Mutual TLS Profiles for OAuth Clients

I support the adoption of this draft by the working group. On Sun, Apr 23, 2017 at 9:11 AM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > +1 for adoption > > Am 21.04.2017 um 21:43 schrieb Nat Sakimura : > > +1 for adoption > > On Apr 21, 2017 9:32 PM, "Dave Tonge" wrote: > >> I suppor

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-08.txt

full authentication credential. This is certainly true for > > password-based authentication mechanisms but I wonder whether this is > > also true for strong authentication techniques, such as those used by > > FIDO combined with token binding. Have you looked into more modern >

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-04.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 of the IETF. > > Title : OAuth 2.0 Device Flow for Browserless and Input > Constrained Devices > Aut

Re: [OAUTH-WG] Device Flow: Alternative to Polling

We've been operating with polling for a while and handle a decent amount of traffic (the YouTube TV app uses it), the polling gets the job done. The simplicity of the protocol definitely helps when used on constrained devices. I like the idea of adding HTTP/2 based long-poll as an optional enhance

Re: [OAUTH-WG] Shepherd Writeup for OAuth 2.0 for Native Apps

Thank you for the write-up Hannes. Version 04 adds an IANA consideration section as promised. In reviewing the IANA considerations, I added a normative reference to RFC7595 where private use of the URI namespace is defined (and which were compliant with already – but I made that more clear as well

Re: [OAUTH-WG] OAuth 2.0 for Native Apps: IPR Confirmation

I know of no IPR disclosures for this document. I have none to make. - William Denniss On Mon, Sep 19, 2016 at 8:49 AM, wrote: > I know of no IPR disclosures for this document. > > > > I have none to make. > > > > John B. > > > > Sent from Mail &

Re: [OAUTH-WG] Mix-Up and CnP/ Code injection

I'm inclined to think that Nat's comment is right: "As I look at it more and more, it started to look like the problem of accepting tainted values without message authentication. To fix the root cause, we would have to authenticate response. ID Token was designed to also serve as a solution anticip

Re: [OAUTH-WG] OAuth 2.1

Fair points. I also think this is an area where good online documentation, and books like *OAuth 2 in Action* can help, and possibly help a lot sooner. On Thu, Apr 7, 2016 at 4:15 PM, Adam Lewis wrote: > +1 > > I will not comment on the timeline for this, but I will passionately > endorse the ne

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

I support the document moving forward, and agree with the proposal to rename it to "OAuth 2.0 Authorization Server Discovery Metadata". Personally I was fine with re-using 'openid-configuration' for compatibility, but I suppose it's not a big burden for everyone who is already using that to setup

Re: [OAUTH-WG] 2nd Call for Adoption: Authentication Method Reference Values

+1 to adopt. My previous concerns of this draft have been addressed, and I am supportive of having an IANA registry of amr values. On Thu, Feb 18, 2016 at 5:09 AM, Hannes Tschofenig < hannes.tschofe...@gmx.net> wrote: > In response to my message to the list regarding the initial call for > adopt

Re: [OAUTH-WG] Call for Adoption: Stateless Client Identifier for OAuth 2

+1 to adopt. I don't think we're planning to use this, but it looks useful and doesn't harm interoperability so I support it. On Sat, Feb 6, 2016 at 3:43 AM, Torsten Lodderstedt wrote: > +1 > > > Am 04.02.2016 um 17:37 schrieb John Bradley: > >> I support it. >> >> I have always thought of this

Re: [OAUTH-WG] OAuth 2.0 for Native Apps: Call for Adoption Finalized

Thank you everyone for your support, and adoption of this document! This spec doesn't modify the OAuth 2.0 protocol, rather it provides a set of technical guidelines for implementing OAuth 2.0 for native apps in a secure and usable way. The intent is a document that has the technical approval of t

Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00)

unless for extremely good reasons, as we don't want to break clients who will start using this. On Mon, Jan 25, 2016 at 4:08 PM, William Denniss wrote: > Thanks Mike, looking forward to the update. I reviewed the other thread. > > On Mon, Jan 25, 2016 at 2:49 PM, Mike Jones >

Re: [OAUTH-WG] Discovery document updates planned

On Thu, Jan 21, 2016 at 10:37 PM, Mike Jones wrote: > Tomorrow I plan to apply updates to the OAuth Discovery document that have > been requested since the -00 version was published. Updates on my list to > make are: > > · Adding an equivalent of token_endpoint_auth_methods_supported for >

Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00)

meter so > code_challenge_methods_supported > > > On Jan 25, 2016, at 6:12 PM, William Denniss wrote: > > > > On Thu, Jan 21, 2016 at 6:17 AM, John Bradley wrote: > >> The code_challenge and code_challenge_method parameter names predate >> calling the spec

Re: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values

On Wed, Jan 20, 2016 at 12:37 PM, Manger, James < james.h.man...@team.telstra.com> wrote: > Accepting draft-jones-oauth-amr-values-03 is almost okay as a starting > point for work. > +1 for adoption. > I would like to see significant changes though: > > * The "amr_values" parameter should be dr

Re: [OAUTH-WG] Google's OAuth endpoints now fully support PKCE (RFC7636)

x27;t > detail the exact cause of the error, but in the "error_description" field > we list all possible causes that a client dev should check - invalid code, > redirect_uri mismatch, bad pkce challenge, etc. > > Cheers, > > Vladimir > > On 19/01/16 07:46, Willia

Re: [OAUTH-WG] OAuth Device Flow

Google has additional documentation here: https://developers.google.com/identity/protocols/OAuth2ForDevices The implementation mostly follows the original draft, but there are a few differences. Also we've learnt a lot about the security and usability implications of this flow along the way, which

Re: [OAUTH-WG] OAuth 2.0 Introspection RFC Issues

We had a debate on that MUST at the last IETF, but the spec was too far along to change. The workaround is to treat the token you are introspecting as the authentication. With that workaround, the spec is quite usable for non-confidential clients, even if resource servers were the primary target.

Re: [OAUTH-WG] Lifetime of refresh token

+1 for John's suggestion. Why force users to re-authenticate after an arbitrary 30-day window? On Fri, Aug 28, 2015 at 1:41 PM John Bradley wrote: > I would use a 5 min AT and roll the refresh token per > https://tools.ietf.org/html/rfc6749#page-47 with a 1 month expiry if that > is what you wa

Re: [OAUTH-WG] Is it allow to add custom attribute to access token response?

You can add additional parameters. "The client MUST ignore unrecognized value names in the response" is there so that other clients who don't understand your parameters will ignore them. That line basically enables the behavior you wanted (if it said the client must *error* on unrecognized values,

Re: [OAUTH-WG] “amr” Values spec updated

– not in the “amr” > value. If you’d like to suggest any edits in that regard, have at it! > > > > Thanks, > > -- Mike > > > > *From:* William Den

Re: [OAUTH-WG] Token introspection for public clients?

> Additionally, the discussion for this was back in December during the >> WGLC, and the time for normative changes to this particular spec is largely >> over at this stage. >> >> — Justin >> >> On Jul 20, 2015, at 12:03 AM, William Denniss >> wro

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt

early indicated as MTI, little is said about "plain", although it's alluded to that it's not MTI in 4.4.1 ("and knows that the server supports "plain""). Should we be more explicit upfront that "plain" is optional for servers to support, if that&#x

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt

t. > > I changed it to t_m rather than “t” I think that is clearer. If I were > to do it the other way XML2RFC would have double quotes in the text version. > > John B. > > On Jul 7, 2015, at 9:38 PM, William Denniss wrote: > > In version 14, there's a t

Re: [OAUTH-WG] draft-ietf-oauth-spop-04: a way of making code_challenge

On Thu, Nov 13, 2014 at 6:00 PM, Nat Sakimura wrote: > Regarding > > > Other problem is the following, using Nat’s slide: > > http://www.slideshare.net/nat_sakimura/1112-spoppresso . > > > > 0.Attacker prepares own code_verifier and code_challenge. > > 1.replage legitimate challenge with