[Openid-specs-ab] WGLC for candidate OpenID Connect errata correction drafts
Vladimir Dzhuvinov
vladimir at connect2id.com
Fri Oct 27 05:17:56 UTC 2023
The URLs are compared as simple strings. If a port is given it is
naturally included.
https://www.rfc-editor.org/rfc/rfc3986.html#section-6.2.1
Vladimir Dzhuvinov
On 26/10/2023 20:41, Tom Jones wrote:
> In general I like this wording.
>
> Sorry I don't have the time to check, but it needs to be clear that
> url matching includes the port number.
>
> ..tom
>
>
> On Thu, Oct 26, 2023 at 10:32 AM Michael Jones via Openid-specs-ab
> <openid-specs-ab at lists.openid.net> wrote:
>
> 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 httpscheme with localhostor the
> IP loopback literals 127.0.0.1or [::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 httpscheme with localhostor the
> IP loopback literals 127.0.0.1or [::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
> *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
> *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
> <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
> *Cc:* Gail Hodges <gail at oidf.org>; Mike Leszcz
> <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 13^th . 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
>
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
> _______________________________________________
> Openid-specs-ab mailing list
> 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/20231027/6a3c53db/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20231027/6a3c53db/attachment-0001.p7s>
More information about the Openid-specs-ab
mailing list