Hi Frederick,
Thanks for your response. Although scope is an optional parameter for an Authorization Code request, the ESPI standard requires it. The third-party registration process requires that all scope profiles are defined as part of their registration process. Therefore, shouldn’t the submission of a scope parameter that matches a defined scope profile be validated, and, if incorrect, return an ?error=invalid_scope response? Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 2335 Dunwoody Crossing Suite E Dunwoody, GA 30338-8221 From: Frederik Krogsdal Jacobsen <[email protected]> Sent: Friday, August 7, 2026 3:35 AM To: [email protected] Cc: [email protected]; Jeremy J. Roberts <[email protected]>; Emelia S. <[email protected]> Subject: Re: [OAUTH-WG] Re: How to properly implement Section 4.1.2.1 Authorization Error Response for OAuth 2.x Hi Donald, I am not familiar with the NAESB ESPI standard, but if it does not use the OpenID Connect standard, then IBM's argument regarding OpenID certification is moot. OpenID Connect does not supersede OAuth 2.0, it merely profiles it for certain purposes. Regarding case 5, the OAuth 2.0 standard says the following in section 3.3: The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner's instructions. This means that you can't expect an authorization server to provide the invalid_scope parameter for any particular scope. The authorization server controls its own policy for when it returns that error. As Emelia said, however, the NAESB ESPI could define a profile of OAuth 2.0 that provides this policy by defining the valid scopes (and maybe it already does; as I mentioned, I am not familiar with it). In that case, however, the question is not about compliance with OAuth 2.0, but rather about compliance with the profile. Cheers, Frederik On Thu, 6 Aug 2026 at 19:43, Emelia S. <[email protected] <mailto:[email protected]> > wrote: Also, Donald, the other thing that should be considered is the format of your scope strings: they're not individual scopes, but rather a payload that's parsed to infer some meaning. This means that the authorization server cannot advertise the scopes supported by that authorization server in the OAuth Authorization Server Metadata response (RFC8414). I would strongly encourage NAESB ESPI to adopt Rich Authorization Requests (RFC9396) in the future, which are specifically designed for these sort of complex authorization requests, and where scope strings often fall short, since they're requiring an exact comparison. For your test case 5, I assumed it was that the scope value was syntactically valid per the RFC, and that the scope was not supported by the authorization server, in which case invalid_scope or silently ignoring is correct. If you instead meant "the scope value does not parse according to NAESB ESPI's parsing logic", well, the specification for that would need to define what the correct behaviour is. Rich Authorization Requests are still probably what you want instead of parsing a scope string as anything more than a space separated set of scopes. — 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> 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> 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> https://...verify.ibm.com/idaas/mtfim/sps/idaas/login... Note: <https://cmdcert.greenbuttonalliance.org:8445/ThirdParty/espi/1_1/OAuthCallback> 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> 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> 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 -- <mailto:[email protected]> [email protected] To unsubscribe send an email to <mailto:[email protected]> [email protected] _______________________________________________ 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]
