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