Re: [OAUTH-WG] Token Revocation error codes

I think one important point Sergey raised was that the response to the client from submitting the wrong token is the same 200 response as submitting a valid token, and that hugely increases the chance that the developer of the client app might submit the wrong token and never realise. Making

Re: [OAUTH-WG] Comments on draft-ietf-oauth-security-topics-06.txt

Hi Denis, > On 22 May 2018, at 14:05, Denis wrote: > In particular, the text states: > >"Clients shall use PKCE [RFC7636] in order to (with the help of the > authorization server) detect and prevent attempts > to inject (replay) authorization codes into the

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt

Hi Torsten, As we briefly spoke about earlier, "3.8.1. Authorization Server as Open Redirector" could I think be made more explicit. Currently it explicitly mentions the invalid_request and invalid_scope errors must not redirect back to the client's registered redirect uri.

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

Hi Aaron, Thanks for putting this document together, I think this kind of guidance is invaluable. It may be worth slightly rewording 7.2 as it may encourage a growing misconception that all native apps must be public clients. With many devices now having embedded HSMs, we’ve seen increasing

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-09.txt

Hi Torsten, A few comments having just read this afresh: 2.1: 'Clients SHALL avoid’ - is that normatively different to ’SHOULD’ given it appears to be permitted? I find it a little hard to understand exactly what "avoid any redirects or forwards which can be parameterized by URI query

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

Hi all, It’s worth adding that a per-instance dynamic registration of a native client can still imply a higher level of trust than a public client and registration isn’t necessarily unauthenticated. https://tools.ietf.org/html/rfc7591 defines an “initial access token”: > OAuth 2.0 access

Re: [OAUTH-WG] Device Authorization Grant Interval

Hi Janak, Interestingly this came up when discussing the CIBA specification (which builds upon device authorization grant to some extent) recently: https://bitbucket.org/openid/mobile/issues/135/token-endpoint-response-when-client-polls The thought that group came up with is that returning

Re: [OAUTH-WG] Question regarding RFC 8628

Hi all, Thanks, Torsten. > On 18 Nov 2019, at 13:22, Torsten Lodderstedt wrote: > > Hi Hervé, > > looping in Joseph. > >> On 18. Nov 2019, at 21:17, Robache Hervé > > wrote: >> >> Thanks Torsten >> >> Yes, we study this flow as well. Actually we consider the

Re: [OAUTH-WG] Question regarding RFC 8628

Hi Hervé > On 18 Nov 2019, at 14:20, Robache Hervé wrote: > > Thanks Joseph > > I agree with you. There should be no issue when the URL is registered during > the TPP app installation. > > From my perspective, this URL should be passed during the authorization > request within the

Re: [OAUTH-WG] embedded UA detection

Hi Giada, All methods can be bypassed by an attacker that has control of the app in question, it’s just a matter of effort. I believe many AS’s use client side javascript to provide a harder to bypass implementation. Your aim here is probably mainly to prevent naive developers “accidentally”

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests

I support the adoption of PAR. Thanks Joseph > On 17 Dec 2019, at 12:59, Rifaat Shekh-Yusef wrote: > > All, > > This is a call for adoption of for the OAuth 2.0 Pushed Authorization > Requests document. > https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ >

Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

ur possible combinations in a very predictable way >> is, I think, the best way to handle backwards compatibility here. >> >> But between this issue and JAR’s problematic call for the value of a >> request_uri to always be a JWT and be fetchable by the AS (neither of whi

Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

I agree with this, particularly the security concerns of merging. If we merge, we can much guarantee there will eventually be a security issue where an attacker is able to gain an advantage by adding a parameter to the url query (which the server would then happily process if that parameter

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests

+1 > On 8 Jan 2020, at 03:31, Steinar Noem wrote: > > +1 > > tir. 7. jan. 2020 kl. 17:53 skrev Torsten Lodderstedt > >: > +1 > > > On 7. Jan 2020, at 17:25, Brian Campbell > > > > wrote: > > > > +1 > > >

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

er | > > ++--+ > > JAR Client | YES| NO | > > OIDC Client | YES| YES | > > > > Breaking one out of the four possible combinations in a very predictable > > way is, I think, th

Re: [OAUTH-WG] Issuers, Discovery Docs & Brands

ible that each brand >> must have its own `issuer` and therefore its own discovery document at the >> correct location (i.e. brand 1 would have an issuer of "https://as/brand1 >> <https://as/brand1>" and a discovery document available at >> https:

Re: [OAUTH-WG] Issuers, Discovery Docs & Brands

ll this chooser provide the client with issuer and brand >>> id? >>> >>>> On 22. May 2020, at 08:10, Vladimir Dzhuvinov >>>> <mailto:vladi...@connect2id.com> wrote: >>>> >>>> A mapping like the one you propose can definitely w

Re: [OAUTH-WG] Issuers, Discovery Docs & Brands

like the one you propose can definitely work. Since the user will >>> be making the choice which endpoint to take with the client app, having the >>> logo_uri is a good idea. If the branded endpoints differ somehow in policy >>> one could also allow inclusion of the op

Re: [OAUTH-WG] [EXTERNAL] Re: Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (with COMMENT)

I agree with Brian here, I think “typ”:”JWT” should be permitted as well as no typ and “typ”: "oauth.authz.req+jwt". There are other tests we could write for JAR that an OIDC server will fail (for example, one that tested the behaviour of passing a value only outside the request object - which

Re: [OAUTH-WG] Namespacing "type" in RAR

I’d agree with this. I’d probably go even further and suggest the specification simply disallow non-ASCII values - it just seems like a minefield that so many people have unsuccessfully attempted to negotiate, and it is not necessary to force or allow AS implementors (or the rest of the

Re: [OAUTH-WG] WGLC on Pushed Authorization Requests draft

Thanks Rifaat, Hannes, and also thanks to all the authors. I’ve been through the latest spec and it basically looks great to me; I raised 3 minor niggles under https://github.com/oauthstuff/draft-oauth-par/issues

Re: [OAUTH-WG] Issuers, Discovery Docs & Brands

Hi Francis, > On 3 Jun 2020, at 18:07, Francis Pouatcha > wrote: > > Hello Dave, > > I agree that the best deployment option is: 1 brand = 1 issuer = 1 discovery > doc, however that is not always possible. > > I'd like to understand Francis what particular issue you see from allowing an >

Re: [OAUTH-WG] Issuers, Discovery Docs & Brands

Hi James, > On 5 Jun 2020, at 03:23, Manger, James > wrote: > If you merely want to trigger a different look-n-feel, define a “brand” > parameter to add the to the authorization request. Unfortunately this doesn’t work when the authorization endpoint is a claimed https url for a mobile app:

Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

I agree, it is in redundant in the JARM case. I find the text in https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html#name-security-considerations (the 4th paragraph where JARM & JWTs) are mentioned a bit confusing - I think it would be good to say something along

Re: [OAUTH-WG] Android App Links (AKA Universal Links)

Hi Dick I didn’t attend the call so don’t know the background of this and the exact situation, but the general problem is mostly where the Authorization Server’s app is *not* installed. In that case Android falls back to much weaker mechanisms that allow other apps to get a look in. App links

Re: [OAUTH-WG] Android App Links (AKA Universal Links)

ave given and matches my > understanding as well. > > Thanks, > George > > On 11/3/20 2:13 PM, Dick Hardt wrote: >> Thanks Joseph. >> >> George Fletcher ran a great session on the topic at the last IIW as well. >> >> George: do you have a link? >&g

Re: [OAUTH-WG] OAuth: The frustrating lack of good libraries

Hi Daniel I do think it’s a problem that’s worth addressing somehow. I think there’s another factor, which is that the providers of OAuth2 Authorization Servers (where they don’t have their own SDKs specific to their server) tend to lead the developer through how to do a “from scratch”

Re: [OAUTH-WG] Comments on ietf-oauth-dpop

Hi Rohan, > On 22 Mar 2022, at 15:24, Rohan Mahy > wrote: > > Here are some comments on draft-ietf-oauth-dpop-06: > > 1) With such a significant attack possible as DPoP proof pre-generation, why > isn't using the server nonce a SHOULD? Preventing a significant attack and > making lifetime

Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List

I support adoption. Joseph > On 30 Sep 2023, at 13:52, Rifaat Shekh-Yusef wrote: > > All, > > This is an official call for adoption for the JWT and CWT Status List draft: > https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/ > > Please, reply on the mailing list and let

Re: [OAUTH-WG] PAR request_uri questions/guidance

Hi Brock Answers inline: > On 28 Sep 2023, at 19:39, Brock Allen wrote: > > Hello -- > > While implementing PAR, some questions came up around the request_uri, > expiration, and one-time use semantics. > > 1: I found this conversation: >

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

I support adoption. Joseph > On 23 Aug 2023, at 20:01, Rifaat Shekh-Yusef wrote: > > All, > > This is an official call for adoption for the Protected Resource Metadata > draft: > https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/ > > Please, reply on the mailing list and

Re: [OAUTH-WG] Draft Proposal for a Cross Device Flow Security BCP

Hi Pieter / Daniel / Filip It’s great to see this document moving forward. I may have missed it, but it may be worth being move explicit that one solution is to avoid using cross-device flows for same-device scenarios? It’s sort of obvious, but questions like “well CIBA works for both

[OAUTH-WG] OAuth security BCP: Lifetime of authorization codes

Hi all I couldn't find any text in the current BCP document about the lifetime of authorization codes, do people think that this may be worth mentioning? The only guidance I could find on authorization code lifetimes is RFC 6749, 4.1.2: "A maximum authorization code lifetime of 10 minutes is

Re: [OAUTH-WG] DPoP - Impementations

Hi Rifaat The OpenID Foundation FAPI2 certification tools have implementations of / tests for (most of) DPoP as both an AS/RS & client. Authlete has implemented DPoP as an AS / RS. Thanks Joseph > On 10 Aug 2022, at 22:39, Rifaat Shekh-Yusef wrote: > > All, > > As part of the shepherd

Re: [OAUTH-WG] Call for adoption - SD-JWT

I support adoption. Joseph Heenan > On 29 Jul 2022, at 01:16, Rifaat Shekh-Yusef wrote: > > All, > > This is a call for adoption for the SD-JWT document > https://datatracker.ietf.org/doc/draft-fett-oauth-selective-disclosure-jwt/ > <https://datatracker.ietf.

Re: [OAUTH-WG] DPoP questions (post IETF 115), part 2

Hi Dmitry Yes, the OpenID Foundation conformance suite will include tests for DPoP as part of the FAPI2 test suite. The tests already exist and can be run, but they are not yet complete (some negative tests are missing, nonces are not yet supported, etc). If you (or anyone else) would like to

Re: [OAUTH-WG] Call for adoption: Cross-Device Flows

Hi all I support adoption of this document. Thanks Joseph > On 15 Nov 2022, at 14:43, Rifaat Shekh-Yusef wrote: > > All, > > During the IETF meeting last week, there was a strong support for the > adoption of the following document as a WG document: >

Re: [OAUTH-WG] Scoring OAuth authorization servers on best practices

Hi It’s not exactly what you asked for, but https://oauch.io/ was aiming to do this - although the online site currently seems to give a 500 error after logging in for me. I’m sure the team behind it were planning to publish the results of the tool, but I can’t remember if they did yet.

Re: [OAUTH-WG] Call for adoption - Transaction Tokens

I support adoption. Joseph > On 14 Nov 2023, at 12:57, Rifaat Shekh-Yusef wrote: > > All, > > This is an official call for adoption for the Transaction Tokens draft: > https://datatracker.ietf.org/doc/draft-tulshibagwale-oauth-transaction-tokens/ > > Please, reply on the mailing list and

Re: [OAUTH-WG] Call for adoption - Identity Chaining

I supported adoption. Joseph > On 14 Nov 2023, at 12:58, Rifaat Shekh-Yusef wrote: > > All, > > This is an official call for adoption for the Identity Chaining draft: > https://datatracker.ietf.org/doc/draft-schwenkschuster-oauth-identity-chaining/ > > Please, reply on the mailing list and