Hi Donald, If you're pre-registering a client with a defined set of scopes, then Section 3.3 of RFC 6749 applies: https://datatracker.ietf.org/doc/html/rfc6749#section-3.3
Yours, Emelia > On 7 Aug 2026, at 23:34, [email protected] wrote: > > 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?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] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[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]
