[Openid-specs-ab] Inconsistency in redirect_uri definitions

John Bradley ve7jtb at ve7jtb.com
Fri Jun 7 18:54:54 UTC 2013


RFC 3986 is about URI generic syntax we would need to point specifically to Simile String Comparison Sec 6.2.1

On 2013-06-07, at 8:48 PM, Tim Bray <tbray at textuality.com> wrote:

> I recommend “REQUIRED. Redirection URI to which the response will be sent. This URI MUST exactly match one of the redirect_uris registered for the client_id, with the matching performed as described in [RFC3986] section 6.2.1”
> 
> 
> On Fri, Jun 7, 2013 at 11:39 AM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> So you’re advocating copying the definition in Messages to Standard and deleting the words “the Scheme, Host, and Path segments of” from Registration, correct?  If not, please supply alternative exact wording.
> 
>  
> 
>                                                             -- Mike
> 
>  
> 
> From: John Bradley [mailto:ve7jtb at ve7jtb.com] 
> Sent: Friday, June 07, 2013 11:33 AM
> To: Tim Bray
> Cc: Mike Jones; openid-specs-ab at lists.openid.net
> 
> 
> Subject: Re: [Openid-specs-ab] Inconsistency in redirect_uri definitions
> 
>  
> 
> Google is comparing them as strings requiring an exact match as I understand it.
> 
>  
> 
> Anything other than an exact match of the the string of octets is likely to fail with some IdP.  It would be nice to do URI to URI comparisons but that tends to have interoperability problems.   From a security point of view Standard is correct and should be copied to the other specs.
> 
>  
> 
> From an interoperability point of view saying it is an exact match of the octets may save a bunch of interoperability issues,.
> 
>  
> 
> Pointing to RFC3986 for comparison rules saying we are not doing normalization and will perform a comparison of the UTF8 code-points to be more specific.
> 
>  
> 
> John
> 
>  
> 
> On 2013-06-07, at 7:45 PM, Tim Bray <tbray at textuality.com> wrote:
> 
> 
> 
> 
> When you say “match Standard” you mean referring to the enumeration of scheme/host/path/query, I assume.  As opposed to the reference to dynamic client registration?  BTW RFC3986 section 6.2 (http://tools.ietf.org/html/rfc3986#section-6.2) has useful material on URI comparison. You could simply refer to 6.2.1 and omit the enumeration.
> 
>  
> 
> On Fri, Jun 7, 2013 at 10:33 AM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> 
> While working on the spelling and grammar check, I noticed the following in redirect_uri definitions.  While I hate to bring this up while we’re trying to finish the Implementer’s Drafts, this is potentially a recall-class issue, so I wanted to raise it now, rather than have it come up later.
> 
>  
> 
> Messages, Basic, and Implicit say:
> 
> redirect_uri
> 
> REQUIRED. Redirection URI to which the response will be sent. This MUST be pre-registered with the OpenID Provider.
> 
>  
> 
> Standard says:
> 
> redirect_uri
> 
> REQUIRED. Redirection URI to which the response will be sent. The Scheme, Host, Path, and Query Parameter segments of this URI MUST match one of the redirect_uris registered for the client_id in the OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration] specification.
> 
>  
> 
> Dynamic Registration says:
> 
> redirect_uris
> 
> REQUIRED. Array of redirection URIs values used in the Authorization Code and Implicit grant types. One of these registered redirection URI values MUST match the Scheme, Host, and Path segments of the redirect_uri parameter value used in each Authorization Request.
> 
>  
> 
> Should Messages, Basic, and Implicit be changed to match Standard?  That’s my sense of the situation, but wanted to get others’ input before doing so.
> 
>  
> 
>                                                             Thanks,
> 
>                                                             -- Mike
> 
>  
> 
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> 
>  
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://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/20130607/658710af/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4507 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130607/658710af/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list