Hi Donald, The 302 you're seeing here is the "The authorization server MUST first verify the identity of the resource owner." from Section 3.1, as that redirect is to their own login page to verify the resource owner first.
The request did include a scope parameter, however, per section 3.3, "The authorization server MAY fully or partially ignore the scope requested by the client", which I assume is what IBM is doing here. So the 302 redirect to their login page is considered valid. Yours, Emelia > On 8 Aug 2026, at 00:54, [email protected] wrote: > > Hi Emelia, > > That is exactly the purpose of case 5, but IBM responds that they never have > to look at the scope parameter. > > Best regards, > Don > Donald F. Coffin > Founder/CTO > > REMI Networks > 2335 Dunwoody Crossing Suite E > Dunwoody, GA 30338-8221 > > From: Emelia S. <[email protected]> > Sent: Friday, August 7, 2026 6:47 PM > To: [email protected] > Cc: Warren Parad <[email protected]>; [email protected]; Jeremy J. Roberts > <[email protected]> > Subject: Re: [OAUTH-WG] How to properly implement Section 4.1.2.1 > Authorization Error Response for OAuth 2.x > > Hi Donald, > > Are you referring to this? > HTTP/1.1 302 Found > Location: https://client.example.com/cb?error=access_denied&state=xyz > Because that is a 3xx redirect with a Location, this is when the > authorization server can complete a redirect back to the client (valid client > ID / redirect URI), but the specific error there is for: The resource owner > or authorization server denied the request. > > Typically that specific error code is when you have a UI that is approve / > deny for the authorization request, but as noted the Authorization Server may > deny the request with this error too. > > So for your cases with invalid scope, when the scope(s) are registered with > the client and the client requests a different set of scopes that do not > intersect with the scopes registered, then the server may respond with: > > HTTP/1.1 302 Found > Location: https://client.example.com/cb?error=invalid_scope&state=xyz > Hope that helps. > > Yours, > Emelia > > >> On 8 Aug 2026, at 00:21, <[email protected] >> <mailto:[email protected]>> <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Emelia, >> >> I understand a 302/303 without a Location header will not work, since that >> is how a redirect knows the target address. >> >> What is confusing me is the example of a 302 response with an error message >> at the bottom of Section 4.1.2.1. Error Response, which does not include a >> location header, implying it is blank, yet the IBM Verify 401 response is >> valid. >> >> Best regards, >> Don >> Donald F. Coffin >> Founder/CTO >> >> REMI Networks >> 2335 Dunwoody Crossing Suite E >> Dunwoody, GA 30338-8221 >> >> From: Emelia S. <[email protected] <mailto:[email protected]>> >> Sent: Friday, August 7, 2026 3:34 PM >> To: [email protected] <mailto:[email protected]> >> Cc: Warren Parad <[email protected] <mailto:[email protected]>>; >> [email protected] <mailto:[email protected]>; Jeremy J. Roberts >> <[email protected] <mailto:[email protected]>> >> Subject: Re: [OAUTH-WG] How to properly implement Section 4.1.2.1 >> Authorization Error Response for OAuth 2.x >> >> Hi Donald, >> >> As mentioned, the first table is wrong for test cases 1, 3, and 4, and would >> lead to open redirector vulnerabilities. The test cases in the second table >> for 1, 3, and 4 are correct. >> >> For test case 0, response_type is required, so yes, redirecting back with >> either invalid_request or unsupported_response_type (if response_type is >> present but not a supported response_type by the authorization server) is >> correct, provided the redirect URI can be validated against the Client. >> >> For test case 5, I'm unclear what the second table is actually showing, the >> correct behaviour here would be to profile OAuth 2.0 in NAESB ESPI to say: >> > if we receive a scope value that does not parse according to <parsing >> > logic>, then the authorization server MUST redirect with "invalid_scope" >> > error, provided all other request details are correct. >> Since as I understand it you are inferring additional details through >> dynamic scopes (this is where I recommend adopting Rich Authorization >> Requests in any future versions of NAESB ESPI, since that would provide the >> richness you're trying to do through parsing scope strings. >> >> You also cannot really do a 302/303 response without a Location header, per >> the HTTP specs: https://www.rfc-editor.org/info/rfc9110/#section-15.4.4 >> You need to say where to redirect to. >> >> Hope that helps. >> >> — Emelia >> >>> On 7 Aug 2026, at 21:12, [email protected] >>> <mailto:[email protected]> wrote: >>> >>> Good afternoon, Emilia and Warren. >>> >>> Thanks for your quick responses. >>> >>> Please clarify which table of results you reference: the first table >>> (expected response) or the second table (IBM Verify responses). If the >>> second table, are you stating these are valid OAuth 2.0 Authorization Flow >>> responses when an OpenID Connect server should be acting like an OAuth 2.0 >>> server without OpenID Connect capability? Can an OpenID Connect server >>> support both OpenID Connect Authentication and perform OAuth 2.0 >>> Authorization? >>> >>> The issue is that we test for compliance with the NAESB ESPI standard, not >>> the OpenID Connect standard, which the ESPI standard does not support. >>> Therefore, the GBA Certification Platform expects the Authorization Server >>> to support the OAuth Authorization Flow requirements. Since I am not >>> familiar with the OpenID Connect specification, is an OpenID Connect >>> solution capable of supporting an OAuth Authorization Flow? >>> >>> Is there a hierarchical relationship between OpenID Connect and the IETF >>> RFC 6749 OAuth 2.0 standard? According to IBM, the OpenID Connect >>> specification supersedes the IETF RFC 6749 OAuth 2.0 standard and should >>> therefore the OAuth 2.0 implementation should support the OpenID Connect >>> Authorization Flow specification. In reviewing the OpenID Connect >>> specification, the Authorization Flow section states that for an OpenID >>> Connect Hybrid Flow, the Authorization Flow should follow the OAuth 2.0 >>> standard. Does this indicate there is no hierarchical relationship between >>> the OpenID Connect and OAuth 2.0 standards? >>> >>> Best regards, >>> Don >>> Donald F. Coffin >>> Founder/CTO >>> >>> REMI Networks >>> 2335 Dunwoody Crossing Suite E >>> Dunwoody, GA 30338-8221 >>> >>> From: Emelia S. <[email protected] <mailto:[email protected]>> >>> Sent: Thursday, August 6, 2026 1:23 PM >>> To: [email protected] <mailto:[email protected]> >>> Cc: [email protected] <mailto:[email protected]>; Jeremy J. Roberts >>> <[email protected] <mailto:[email protected]>> >>> Subject: Re: [OAUTH-WG] How to properly implement Section 4.1.2.1 >>> Authorization Error Response for OAuth 2.x >>> >>> Hi Donald, >>> >>> Looking at the table of results and test cases, for 1, 3 and 4, these are >>> the correct responses per the results table, as otherwise the authorization >>> server would be an open redirector. For test case 0, the response_type is >>> required, so yes, redirecting back with the error of either >>> invalid_request, or unsupported_response_type if it's present but >>> unsupported, would be correct. For test case 5, redirecting back with >>> invalid_scope would be correct, provided the client and redirect URI match. >>> >>> Do be careful not to mixup response_type (OAuth, OIDC) and response_mode >>> (from OIDC), response_mode can often be inferred from response_type (e.g., >>> code response_type often defaults to query as a response_mode). >>> >>> Hope that helps. >>> >>> Yours, >>> Emelia >>> >>> >>> >>> >>>> On 6 Aug 2026, at 18:30, [email protected] >>>> <mailto:[email protected]> wrote: >>>> >>>> I am the Technical Manager of the Green Button Alliance. I am responsible >>>> for certifying that electric, natural gas, and water utilities comply with >>>> the North American Energy Standards (NAESB) Energy Service Provider >>>> Interface (ESPI) standard and need a ruling from the IETF OAuth WG >>>> regarding an issue that has arisen for Hydro One Networks, Inc. >>>> >>>> Hydro One Networks, Inc., the largest electric utility in Ontario, Canada, >>>> implemented the NAESB ESPI (a.k.a. Green Button) standard in 2023, which >>>> uses the OAuth 2.0 standard for customers to authorize client applications >>>> to access their energy data. At the time, they were using an IBM Tivoli >>>> Authorization Server, which fully complied with the Green Button Alliance >>>> legislatively mandated certification test for Section 4.1.2.1. >>>> Authorization Error Response. They recently upgraded to the IBM Verify >>>> Authorization Server, which no longer passes the same Section 4.1.2.1. >>>> Authorization Error Response tests. IBM has agreed to comply with the >>>> IETF OAuth Working Group’s response to my questions. >>>> >>>> The GBA Certification test platform currently submits the following >>>> invalid Authorization Endpoint requests and expects the Authorization >>>> Server to comply with Section 4.1.2.1. Authorization Error Response error >>>> messages: >>>> >>>> iTestID >>>> Label >>>> Test Name >>>> Query string >>>> Status Code >>>> Expected Error Message >>>> 0 >>>> Case 0: no response_type >>>> Malformed Authorization Code Request (No response_type field-value) >>>> ?client_id=(client_id)&redirect_uri=(redirect_uri)&scope=(scope)&state=ee148ec2-9898-466e-a013-4dedf1eb3018 >>>> 302/303 >>>> ?error=invalid_request parameter and no or empty location header >>>> 1 >>>> Case 1: no client_id >>>> Malformed Authorization Code Request (No client_id field-value) >>>> ?response_type=code&redirect_uri=(redirect_uri)&scope=(scope)&state=ee148ec2-9898-466e-a013-4dedf1eb3018 >>>> 302/303 >>>> ?error=invalid_request parameter and no or empty location header >>>> 2 >>>> Case 2: invalid response_type >>>> Malformed Authorization Code Request (Invalid response_type field-value: >>>> ?response_type=badresponsetype& >>>> client_id=(client_id)&redirect_uri=(redirect_uri)&scope=(scope)&state=ee148ec2-9898-466e-a013-4dedf1eb3018 >>>> 302/303 >>>> ?error=unsupported_response_type parameter and no or empty location header >>>> 3 >>>> Case 3: invalid client_id >>>> Malformed Authorization Code Request (Invalid client_id field-value) >>>> ?response_type=code& >>>> client_id=invalid_third_party&redirect_uri=(redirect_uri)&scope=(scope)&state=ee148ec2-9898-466e-a013-4dedf1eb3018 >>>> 302/303 >>>> ?error=unauthorized_client parameter and no or empty location header >>>> 4 >>>> Case 4: invalid redirect_uri >>>> Malformed Authorization Code Request (Invalid redirect_uri field-value) >>>> ?response_type=code& >>>> client_id=(client_id)&redirect_uri=https://services.greenbuttondata.org&scope=(scope)&state=ee148ec2-9898-466e-a013-4dedf1eb3018 >>>> >>>> <https://services.greenbuttondata.org&scope=(scope)&state=ee148ec2-9898-466e-a013-4dedf1eb3018/> >>>> >>>> 302/303 >>>> ?error=invalid_request parameter and no or empty location header >>>> 5 >>>> Case 5: invalid scope >>>> Malformed Authorization Code Request (Invalid scope field-value) >>>> ?response_type=code& >>>> client_id=(client_id)&redirect_uri=(redirect_uri)&scope=FB=????&state=ee148ec2-9898-466e-a013-4dedf1eb3018 >>>> 302/303 >>>> ?error=invalid_scope parameter and no or empty location header >>>> >>>> All scope string values are application variable contents shown as () >>>> entries if present. Malformed values are shown as strings. I do not test >>>> for missing state= elements, although the NAESB ESPI standard requires >>>> them. >>>> >>>> The following table contains the current response by the IBM Verify >>>> Authorization Server for each of the above test cases: >>>> >>>> >>>> >>>> >>>> >>>> iTestID >>>> Status Code >>>> Response >>>> 0 >>>> 303 >>>> https://cmdcert.greenbuttonalliance.org:8445/ThirdParty/espi/1_1/OAuthCallBack?error=unsupported_response_type&error_description=... >>>> 1 >>>> 401 >>>> The response included a full-screen HTML showing the error “CSIAQ0154E The >>>> requested OAuth 2.0 Client does not exist” >>>> 2 >>>> 303 >>>> https://cmdcert.greenbuttonalliance.org:8445/ThirdParty/espi/1_1/OAuthCallBack?error=unsupported_response_type&error_description... >>>> 3 >>>> 401 >>>> The response included a full-screen HTML showing the error “CSIAQ0154E The >>>> requested OAuth 2.0 Client does not exist” >>>> 4 >>>> 400 >>>> The response included a full-screen HTML showing the error “CSIAQ0167E The >>>> redirection URI provided in the request is either invalid or does not >>>> match any of the OAuth 2.0 Client’s pre-registered redirect URLs” >>>> 5 >>>> 302 >>>> https://...verify.ibm.com/idaas/mtfim/sps/idaas/login... >>>> >>>> Note: >>>> https://cmdcert.greenbuttonalliance.org:8445/ThirdParty/espi/1_1/OAuthCallback >>>> is the value of the redirect_uri for all but the negative redirect_uri >>>> tests >>>> >>>> The IBM team indicated that case 5 (invalid scope): The OpenID Connect >>>> spec allows ignoring unknown scopes vs. returning an invalid_scope error >>>> (https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest). The >>>> referenced section of the OpenID Connect standard is the Authentication >>>> section, which is NOT what case 5 is testing. However, Section 3.1.2.2. >>>> Authentication Request Validation of the OpenID Connect specification >>>> indicates the Authorization Server MUST validate all the OAuth 2.0 >>>> parameters according to the OAuth 2.0 specification. That includes (2) >>>> verifying that a scope parameter is present and contains the openid scope >>>> value (If no openid scope value is present, the request may still be a >>>> valid OAuth 2.0 request but is not an OpenID Connect request). >>>> The IBM team indicated that case 4 (invalid redirect): An OpenID Connect >>>> certification has precedence over the IETF OAuth 2.0 RFC 6749 and >>>> referenced their official OpenID Foundation cert test for invalid redirect >>>> URI, which expects an error page, not a redirect >>>> (https://www.certification.openid.net/log-detail.html?log=Lbzq5uCWSM1Sij3&public=true). >>>> The NAESB ESPI standard does not support the OpenID Connect standard, so >>>> we contend that the IBM Verify team’s position that their OpenID Connect >>>> server does not need to comply with the IETF RFC 6749 and 6750 standards >>>> is a “red herring”. For cases 0 and 2, they have demonstrated the ability >>>> to support Section 4.1.2.4 Authorization Error Response properly. >>>> >>>> The business issue and why I am submitting this email is that Hydro One >>>> Networks, Inc. is required by Ontario legislation to be certified by the >>>> Green Button Alliance as being in compliance with the NAESB ESPI standard. >>>> Without that certification, Hydro One Networks, Inc. will face continuing >>>> financial penalties from the Ontario Energy Board. >>>> >>>> >>>> Best regards, >>>> Don >>>> Donald F. Coffin >>>> Founder/CTO >>>> >>>> REMI Networks >>>> 2335 Dunwoody Crossing Suite E >>>> Dunwoody, GA 30338-8221 >>>> >>>> _______________________________________________ >>>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>>> To unsubscribe send an email to [email protected] >>>> <mailto:[email protected]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
