Using "redirection URIs" is fine with me.
From: Richer, Justin P. [mailto:[email protected]]
Sent: Tuesday, July 08, 2014 8:57 PM
To: Mike Jones
Cc: [email protected] list
Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata
requirements
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 protected]<mailto:[email protected]>> 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 protected]]
Sent: Tuesday, July 08, 2014 8:41 PM
To: Mike Jones
Cc: [email protected]<mailto:[email protected]> list
Subject: Re: [OAUTH-WG] Dynamic Client Registration: comment on metadata
requirements
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 protected]<mailto:[email protected]>> wrote:
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 protected]<mailto:[email protected]>> 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:
The implementation and use of all client metadata fields is OPTIONAL, other
than "redirect_uris"
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 protected]] On Behalf Of Richer, Justin P.
Sent: Tuesday, July 08, 2014 6:44 PM
To: [email protected]<mailto:[email protected]> list
Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata
requirements
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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
