[Openid-specs-ab] WGLC for candidate OpenID Connect errata correction drafts

Thu Oct 26 17:31:27 UTC 2023

Looking at this again, I now believe that the right addition is:

redirect_uri
REQUIRED. Redirection URI to which the response will be sent. This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider, with the matching performed as described in Section 6.2.1 of [RFC3986]<https://openid.net/specs/openid-connect-core-1_0-33.html#RFC3986> (Simple String Comparison). When using this flow, the Redirection URI SHOULD use the https scheme; however, it MAY use the http scheme, provided that the Client Type is confidential, as defined in Section 2.1 of OAuth 2.0, and provided the OP allows the use of http Redirection URIs in this case. Also, if the Client is a native application, it MAY use the http scheme with localhost or the IP loopback literals 127.0.0.1 or [::1] as the hostname. The Redirection URI MAY use an alternate scheme, such as one that is intended to identify a callback into a native application.

Please confirm.

                                                       -- Mike

From: Vladimir Dzhuvinov <vladimir at connect2id.com>
Sent: Thursday, October 26, 2023 8:00 AM
To: Michael Jones <michael_b_jones at hotmail.com>; Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] WGLC for candidate OpenID Connect errata correction drafts

Thanks Mike. This change should do it to align the OIDC code flow redirect_uri with the rest of the updated specs.

Vladimir Dzhuvinov

On 26/10/2023 17:38, Michael Jones wrote:

Thanks for catching this, Vladimir.

Is this the kind of wording you were looking for at https://openid.net/specs/openid-connect-core-1_0-33.html#AuthRequest ?

redirect_uri
REQUIRED. Redirection URI to which the response will be sent. This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider, with the matching performed as described in Section 6.2.1 of [RFC3986]<https://openid.net/specs/openid-connect-core-1_0-33.html#RFC3986> (Simple String Comparison). When using this flow, the Redirection URI SHOULD use the https scheme; however, it MAY use the http scheme, provided that the Client Type is confidential, as defined in Section 2.1 of OAuth 2.0, and provided the OP allows the use of http Redirection URIs in this case. It MAY also use the http scheme with localhost or the IP loopback literals 127.0.0.1 or [::1] as the hostname. The Redirection URI MAY use an alternate scheme, such as one that is intended to identify a callback into a native application.

                                                       -- Mike

From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net><mailto:openid-specs-ab-bounces at lists.openid.net> On Behalf Of Vladimir Dzhuvinov via Openid-specs-ab
Sent: Thursday, October 26, 2023 4:10 AM
To: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Cc: Vladimir Dzhuvinov <vladimir at connect2id.com><mailto:vladimir at connect2id.com>
Subject: Re: [Openid-specs-ab] WGLC for candidate OpenID Connect errata correction drafts

Regarding
Fixed #2026: Clarified description of loopback hostnames for native applications.

I noticed that in OIDC Core the change was applied to the implicit flow and the code flow section not changed.

https://bitbucket.org/openid/connect/pull-requests/620

https://openid.net/specs/openid-connect-core-1_0-33.html#ImplicitAuthRequest
redirect_uri
REQUIRED. Redirection URI to which the response will be sent. This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider, with the matching performed as described in Section 6.2.1 of [RFC3986]<https://openid.net/specs/openid-connect-core-1_0-33.html#RFC3986> (Simple String Comparison). When using this flow, the Redirection URI MUST NOT use the http scheme unless the Client is a native application, in which case it MAY use the http scheme with localhost or the IP loopback literals 127.0.0.1 or [::1] as the hostname.

I was expecting that this errata would apply to the code flow as well, and that the redirect_uri spec here will be aligned with the updated application_type spec in OIDC Dynamic Client Registration. I think this is crucial, developers today are typically concerned with the code flow.

https://openid.net/specs/openid-connect-core-1_0-33.html#AuthRequest
redirect_uri
REQUIRED. Redirection URI to which the response will be sent. This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider, with the matching performed as described in Section 6.2.1 of [RFC3986]<https://openid.net/specs/openid-connect-core-1_0-33.html#RFC3986> (Simple String Comparison). When using this flow, the Redirection URI SHOULD use the https scheme; however, it MAY use the http scheme, provided that the Client Type is confidential, as defined in Section 2.1 of OAuth 2.0, and provided the OP allows the use of http Redirection URIs in this case. The Redirection URI MAY use an alternate scheme, such as one that is intended to identify a callback into a native application.

Vladimir Dzhuvinov

On 22/10/2023 02:26, Michael Jones via Openid-specs-ab wrote:
The 45-day foundation-wide review is now under way, as announced at https://openid.net/review-second-proposed-errata-openid-connect-specifications/ and https://twitter.com/openid/status/1715869175376396543.

Thanks to Mike Leszcz for making the blog post.

                                                       -- Mike

From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net><mailto:openid-specs-ab-bounces at lists.openid.net> On Behalf Of Michael Jones via Openid-specs-ab
Sent: Monday, October 2, 2023 6:19 PM
To: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Cc: Michael Jones <michael_b_jones at hotmail.com><mailto:michael_b_jones at hotmail.com>
Subject: [Openid-specs-ab] WGLC for candidate OpenID Connect errata correction drafts

This note begins a two-week Working Group Last Call (WGLC) for the candidate errata correction drafts below.  The WGLC concludes as of the working group call on Monday, October 16.

Please let us know if you believe that any changes need to be made to these drafts before the Foundation-wide 45-day review for them.  Please identify any proposed changes by filing issues at https://bitbucket.org/openid/connect/issues?status=new&status=open marked with the Errata milestone.

This should put us on track to have approved errata drafts published by the second week of December.

                                         -- Mike (writing as co-chair)

From: Michael Jones
Sent: Sunday, October 1, 2023 12:26 AM
To: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Cc: Gail Hodges <gail at oidf.org<mailto:gail at oidf.org>>; Mike Leszcz <mike.leszcz at oidf.org<mailto:mike.leszcz at oidf.org>>
Subject: Second candidate OpenID Connect errata correction drafts published

I’ve published drafts incorporating all the additional errata corrections that have been approved for the OpenID Connect family of specifications since the first set of candidate drafts were published on August 13th.  This puts us on the doorstep of publishing our second errata set for OpenID Connect and for submission to ISO as Publicly Available Specification (PAS) standards.

The drafts incorporating the errata corrections are:

  1.  https://openid.net/specs/openid-connect-core-1_0-33.html
  2.  https://openid.net/specs/openid-connect-discovery-1_0-36.html
  3.  https://openid.net/specs/openid-connect-registration-1_0-38.html
  4.  https://openid.net/specs/openid-connect-backchannel-1_0-12.html

The History sections of the specs describe each of the changes made.  If you want to see the precise changes incorporated, I suggest using your favorite HTML-capable diff tool (such as Microsoft Word) and comparing the baseline docs below to the ones above:

  1.  https://openid.net/specs/openid-connect-core-1_0-errata1.html
  2.  https://openid.net/specs/openid-connect-discovery-1_0-errata1.html
  3.  https://openid.net/specs/openid-connect-registration-1_0-errata1.html
  4.  https://openid.net/specs/openid-connect-backchannel-1_0-final.html

Diffs are also possible for the .txt and .xml versions of the specs; just substitute “html” in the URLs above for “txt” or “xml” and use your favorite diff tool.

I plan to ask for working group review of these changes during Monday’s working group call.  Following the working group review, we’ll hold the foundation-wide 45-day proposed errata review and then the approval vote.

                                                       -- Mike

P.S.  Our two Implementer’s Guides were also updated in parallel to keep them current with the versions incorporating errata corrections.  The corresponding versions are:

  1.  https://openid.net/specs/openid-connect-basic-1_0-45.html
  2.  https://openid.net/specs/openid-connect-implicit-1_0-28.html

_______________________________________________

Openid-specs-ab mailing list

Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>

https://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20231026/bd98a25e/attachment-0001.html>