Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements

From: "Richer, Justin P." <[email-masked]>
Date: Wed, 9 Jul 2014 01:44:08 +0000

In draft -18, we clarified the optionality of the client metadata parameters in § 2 with new text, including the sentences:

The implementation and use of all client metadata fields is OPTIONAL, other than "redirect_uris".

redirect_uris (...) Authorization servers MUST implement support for this metadata value.

However, since OAuth core defines two non-redirect flows (client credentials and password) and we're about to publish another one (assertions), I suggest that we adopt the following clarification:

The implementation and use of all client metadata fields is OPTIONAL, other than "redirect_uris"

which is REQUIRED for authorization servers that support redirect-based grant types.

Authorization servers that support dynamic registration of clients using redirect-based

grant types MUST implement support for this metadata value.

I think this language brings the requirement more in line with the intent and would like comment from the WG.

 -- Justin

---

From: John Bradley <[email-masked]>
Date: Tue, 8 Jul 2014 22:15:47 -0400

Yes that is reasonable.  

Sent from my iPhone

> On Jul 8, 2014, at 9:44 PM, "Richer, Justin P." <[email-masked]> wrote:
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Mike Jones <[email-masked]>
Date: Wed, 9 Jul 2014 02:22:51 +0000

That's close but not quite right, since use is required by clients when using redirect-based grant types.  We could however, use this language:

which is REQUIRED for authorization servers that support and clients that use redirect-based grant types.

redirect_uris (...) Authorization servers that support dynamic registration of clients using redirect-based

grant types MUST implement support for this metadata value and clients that use redirect-based grant types MUST use this parameter.

                                                            -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Richer, Justin P.
Sent: Tuesday, July 08, 2014 6:44 PM
To: [email-masked] list
Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements

 -- Justin

---

From: "Richer, Justin P." <[email-masked]>
Date: Wed, 9 Jul 2014 03:39:07 +0000

I can see where you're going with it. Requiring clients to use it implies that servers need to enforce it. In the security considerations we currently have:

   For clients that use redirect-based grant types such as
   "authorization_code" and "implicit", authorization servers MUST
   require clients to register their "redirect_uri" values.  This can
   help mitigate attacks where rogue actors inject and impersonate a
   validly registered client and intercept its authorization code or
   tokens through an invalid redirection URI or open redirector.

However, in previous versions up to -17, this was a SHOULD, not a MUST. This is a normative requirement change for server implementors and I want to make sure everyone realizes was made. As of a handful of versions ago, our server started to enforce this anyway. What have other developers done with this, and would it be difficult to comply with the new requirement?

 -- Justin

On Jul 8, 2014, at 10:22 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

That’s close but not quite right, since use is required by clients when using redirect-based grant types.  We could however, use this language:

                                                            -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Richer, Justin P.
Sent: Tuesday, July 08, 2014 6:44 PM
To: [email-masked]<mailto:[email-masked]> list
Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements

 -- Justin

---

From: "Richer, Justin P." <[email-masked]>
Date: Wed, 9 Jul 2014 03:41:13 +0000

Also, I just noticed that paragraph has a typo: "redirect_uri" should be "redirect_uris".

 -- Justin

On Jul 8, 2014, at 11:39 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

 -- Justin

                                                            -- Mike

 -- Justin

---

From: Phil Hunt <[email-masked]>
Date: Tue, 8 Jul 2014 20:45:36 -0700

What about the whole issue of redirect_uri fragments? 

Are there any issues where a client for some reason can’t register a perm URI at registration time?

Phil

@independentid
www.independentid.com
[email-masked]

On Jul 8, 2014, at 8:39 PM, Richer, Justin P. <[email-masked]> wrote:

> On Jul 8, 2014, at 10:22 PM, Mike Jones <[email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 9 Jul 2014 03:51:15 +0000

According to RFC 6749, it must be a MUST.  http://tools.ietf.org/html/rfc6749#section-2 says:

   When registering a client, the client developer SHALL:

   o  provide its client redirection URIs as described in Section 3.1.2<http://tools.ietf.org/html/rfc6749#section-3.1.2>,

SHALL doesn't fulfill this requirement.  That's why I made the change when doing the editorial work to say which metadata values are optional and which are required.

                                                            -- Mike

From: Richer, Justin P. [mailto:[email-masked]]
Sent: Tuesday, July 08, 2014 8:39 PM
To: Mike Jones
Cc: [email-masked] list
Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements

 -- Justin

                                                            -- Mike

 -- Justin

---

From: Mike Jones <[email-masked]>
Date: Wed, 9 Jul 2014 03:52:21 +0000

This isn't a typo.  They are registering their "redirect_uri" values.  They do so using the "redirect_uris" parameter.

                                                            -- Mike

From: Richer, Justin P. [mailto:[email-masked]]
Sent: Tuesday, July 08, 2014 8:41 PM
To: Mike Jones
Cc: [email-masked] list
Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements

 -- Justin

 -- Justin

                                                            -- Mike

 -- Justin

---

From: "Richer, Justin P." <[email-masked]>
Date: Wed, 9 Jul 2014 03:56:56 +0000

Well, I think it's confusing, then. To me, it reads like a typo since it's formatted as a verb. I really think it should line up with the actual name of the parameter, or it shouldn't be formatted as a verb. So I'd suggest either:

    register their "redirect_uris" value

or:

    register their redirection URIs

The latter probably reads better.

  -- Justin

On Jul 8, 2014, at 11:52 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

This isn’t a typo.  They are registering their “redirect_uri” values.  They do so using the “redirect_uris” parameter.

                                                            -- Mike

From: Richer, Justin P. [mailto:[email-masked]]
Sent: Tuesday, July 08, 2014 8:41 PM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]> list
Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements

 -- Justin

 -- Justin

                                                            -- Mike

 -- Justin

---

From: Mike Jones <[email-masked]>
Date: Wed, 9 Jul 2014 19:13:49 +0000

Using "redirection URIs" is fine with me.

From: Richer, Justin P. [mailto:[email-masked]]
Sent: Tuesday, July 08, 2014 8:57 PM
To: Mike Jones
Cc: [email-masked] list
Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements

or:

  -- Justin

                                                            -- Mike

 -- Justin

 -- Justin

                                                            -- Mike

 -- Justin

---

From: John Bradley <[email-masked]>
Date: Wed, 9 Jul 2014 16:04:01 -0400

What issue of redirect_uri fragments?

For implicit and the hybrid flows the fragment is used to pass back the parameters.   

In Connect we were explicit on what parts of the URI are compared:
One of these registered Redirection URI values MUST exactly match the redirect_uri parameter value used in each Authorization Request, with the matching performed as described in Section 6.2.1 of [RFC3986] (Simple String Comparison).

In the IETF version we point back to Section 2 of RFC6749

The redirection endpoint URI MUST be an absolute URI as defined by
   [RFC3986] Section 4.3.  The endpoint URI MAY include an
   "application/x-www-form-urlencoded" formatted (per Appendix B) query
   component ([RFC3986] Section 3.4), which MUST be retained when adding
   additional query parameters.  The endpoint URI MUST NOT include a
   fragment component.

So the redirect_uri can't contain a fragment. 

In RFC6749 there is some wiggle room for comparing URI components.
   When a redirection URI is included in an authorization request, the
   authorization server MUST compare and match the value received
   against at least one of the registered redirection URIs (or URI
   components) as defined in [RFC3986] Section 6, if any redirection
   URIs were registered.  If the client registration included the full
   redirection URI, the authorization server MUST compare the two URIs
   using simple string comparison as defined in [RFC3986] Section 6.2.1.

So we are not adding any additional constraints beyond RFC6749.
The redirect_uris meta-data is optional.

A client using the client credentials or resource owner flow wouldn't have a redirect uri to register.

John B.