So what's the question? On Thu, Aug 6, 2026 at 6:30 PM <[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 > > Dunwoody, GA 30338-8221 > > > _______________________________________________ > 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]
