[Openid-specs-ab] [openid/connect] Inconsistent treatment of redirect_uri parameter (issue #669)

Mike Jones Michael.Jones at microsoft.com
Mon Dec 3 22:59:56 UTC 2012


Brian, last week the working group made this request of you to drive a discussion on this issue:



It is this way because currently Google always requires the redirect_uri value. Brian, could you start a thread on the list with Breno and Naveen asking if they'd be OK with relaxing the spec to allow the redirect_uri parameter not to be present when only one redirect_uri is registered?

Similarly, for the same reasons, we currently require sending the redirect_uri to the token endpoint even in cases where OAuth doesn't require it because we already have a single registered redirect_uri. We should probably discuss this at the same time.



Could you try to get that going this week?  We'd like to decide soon whether any changes will be made in response to this issue.



                                                                Thanks,

                                                                -- Mike



-----Original Message-----
From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Brian Campbell
Sent: Friday, October 19, 2012 2:13 PM
To: openid-specs-ab at lists.openid.net
Subject: [Openid-specs-ab] [openid/connect] Inconsistent treatment of redirect_uri parameter (issue #669)



--- you can reply above this line ---



New issue 669: Inconsistent treatment of redirect_uri parameter https://bitbucket.org/openid/connect/issue/669/inconsistent-treatment-of-redirect_uri



Brian Campbell:



OAuth 2.0 (RFC 6749!) defines redirect_uri as an optional parameter in an authorization request in cases where the client has a single unambiguous redirect_uri registered with the AS and then only requires it in an access token request when it had previously been included in the corresponding authorization request [1].



The treatment of redirect_uri in the Connect specs isn't always consistent with OAuth, however, and is also somewhat internally inconsistent though different Connect specs.



Standard has redirect_uri required in the authorization request [2] while allowing it to be omitted in the token request [3]. Messages has it required [4] as does Basic [5] and Implicit [6]. The wording in Registration seem to suggest that it's required [7].



I'd argue that Connect should be consistent with the OAuth for redirect_uri treatment. It should be optional/required under the same conditions as in OAuth (unless there is some compelling reason to differ). It might make sense to just defer directly to OAuth for the core parameter definitions and only define in Connect additional parameters or those that do need to be treated differently.





[1] http://tools.ietf.org/html/rfc6749#section-3.1.2.3

http://tools.ietf.org/html/rfc6749#section-4.1.1

http://tools.ietf.org/html/rfc6749#section-4.1.3

http://tools.ietf.org/html/rfc6749#section-4.2.1



[2] http://openid.net/specs/openid-connect-standard-1_0.html#rf_prep

[3] http://openid.net/specs/openid-connect-standard-1_0.html#anchor9

[4] http://openid.net/specs/openid-connect-messages-1_0.html#auth_req

[5] http://openid.net/specs/openid-connect-basic-1_0.html#rf_prep

[6] http://openid.net/specs/openid-connect-implicit-1_0.html#rf_prep

[7] http://openid.net/specs/openid-connect-registration-1_0.html#anchor3











--



This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

_______________________________________________

Openid-specs-ab mailing list

Openid-specs-ab at lists.openid.net<mailto: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/20121203/70214dcc/attachment-0001.html>


More information about the Openid-specs-ab mailing list