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 sakim...@gmail.com 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

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

. If you’d like to suggest any edits in that regard, have at it! Thanks, -- Mike *From:* William Denniss [mailto:wdenn...@google.com] *Sent:* Friday, August 14, 2015 1:40

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,

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

for the next draft. 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 wdenn...@google.com wrote: In version 14, there's a typo on this line (deso

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

be more explicit upfront that plain is optional for servers to support, if that's the intention? On Tue, Jul 7, 2015 at 10:51 PM, William Denniss wdenn...@google.com wrote: t_m works for me, I just think we should have some indication that it's the name of the transform. Will you also update

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 ve7...@ve7jtb.com 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

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

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

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

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 <wdenn...@google.com> wrote: > Thanks Mike, looking forward to the update. I reviewed the other thread. > > On Mon, Jan 25, 2016 at 2:49 PM, Mike Jo

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

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

code_challenge_method is the query parameter so > code_challenge_methods_supported > > > On Jan 25, 2016, at 6:12 PM, William Denniss <wdenn...@google.com> wrote: > > > > On Thu, Jan 21, 2016 at 6:17 AM, John Bradley <ve7...@ve7jtb.com> wrote: > >> The code_challenge and

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

- i.e. we don'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,

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 >

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] 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

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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-04.txt

trained Devices > Authors : William Denniss > John Bradley > Michael B. Jones > Hannes Tschofenig > Filename: draft-ietf-oauth-device-flow-04.txt > Pages : 15

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

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

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, <ve7...@ve7jtb.com> wrote: > I know of no IPR disclosures for this document. > > > > I have none to make. > > > > John

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"

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 >

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 <a...@nostrum.com> wrote: > On 6/2/17

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 >

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 <a...@nostrum.com> 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 <wdenn...@google.com

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

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

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

y 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 < > > andrewsciber...@pingidentity.com>

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

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] 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

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: [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

gt; > 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. > > > >Tit

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] 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] 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] 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

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

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

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,

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

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

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] [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

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

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