Two sections define Authorization endpoint errors. 4.1.2.1, which describes errors directed at the client, and § 3.1.2.4 <https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2.4>, which describes errors directed at the user. Case 4 falls under §3.1.2.4, not § 4.1.2.1:
If an authorization request fails validation due to a missing, invalid, or mismatching redirection URI, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirection URI. So the authorization server *_can_* respond however it wants, so long as it informs the user of an error and does not redirect the user-agent back to the client. The 401 HTML response from IBM does this, and so is valid. On Fri, Aug 7, 2026 at 3:40 PM <[email protected]> wrote: > Hi Warren, > > Yes. Section 4.1.2.1 does not specifically state that a 401 is how a > server should respond. > > > > Best regards, > > Don > > Donald F. Coffin > > Founder/CTO > > > > REMI Networks > > 2335 Dunwoody Crossing Suite E > > Dunwoody, GA 30338-8221 > > > > *From:* Warren Parad <[email protected]> > *Sent:* Friday, August 7, 2026 6:22 PM > *To:* [email protected] > *Cc:* Emelia S. <[email protected]>; oauth <[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 > > > > It goes both ways, unless forbidden, it might as well be allowed... So > which scenario do you see you are running up against, where the RFC > explicitly forbids a 401 response? > > > > On Sat, Aug 8, 2026, 00:15 <[email protected]> wrote: > > Warren, > > > > Thanks for your quick reply. > > What Section of RFC 6749 allows a 401 status code response for an > Authorization Request? I am confused by the response being correct, since > all OAuth Authorization Requests are 302/303 Redirect responses. > > > > Best regards, > > Don > > Donald F. Coffin > > Founder/CTO > > > > REMI Networks > > 2335 Dunwoody Crossing Suite E > <https://www.google.com/maps/search/2335+Dunwoody+Crossing+Suite+E+Dunwoody,+GA+30338-8221?entry=gmail&source=g> > > Dunwoody, GA 30338-8221 > <https://www.google.com/maps/search/2335+Dunwoody+Crossing+Suite+E+Dunwoody,+GA+30338-8221?entry=gmail&source=g> > > > > *From:* Warren Parad <[email protected]> > *Sent:* Friday, August 7, 2026 3:32 PM > *To:* [email protected] > *Cc:* Emelia S. <[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 > > > > To be clear, regarding the your questions: > > > > Does the IBM Verify Authorization Server properly implement Section > 4.1.2.1. Authorization Error Response per the OAuth standard. > > > > Yes. > > > > 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? > > > > No, these are valid OAuth 2.0 Authorization Flow responses. > > > > Is there a hierarchical relationship between OpenID Connect and the IETF > RFC 6749 OAuth 2.0 standard? > > > > No, there is no relationship. > > > > > > > > > > On Fri, Aug 7, 2026 at 9:13 PM <[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 > <https://www.google.com/maps/search/2335+Dunwoody+Crossing+Suite+E+Dunwoody,+GA+30338-8221?entry=gmail&source=g> > > Dunwoody, GA 30338-8221 > <https://www.google.com/maps/search/2335+Dunwoody+Crossing+Suite+E+Dunwoody,+GA+30338-8221?entry=gmail&source=g> > > > > *From:* Emelia S. <[email protected]> > *Sent:* Thursday, August 6, 2026 1:23 PM > *To:* [email protected] > *Cc:* [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, > > > > 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] 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 > > 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 > <https://www.google.com/maps/search/2335+Dunwoody+Crossing+Suite+E+Dunwoody,+GA+30338-8221?entry=gmail&source=g> > > Dunwoody, GA 30338-8221 > <https://www.google.com/maps/search/2335+Dunwoody+Crossing+Suite+E+Dunwoody,+GA+30338-8221?entry=gmail&source=g> > > > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
