(+1) pro any client-specific parameters
That's the way OAuth 1.0a and OpenId 2.0 handle it, why deviate?
Am 09.04.2010 19:43, schrieb Eran Hammer-Lahav:
I'm opposed to having both any parameters and a state parameter. Pick
one. OAuth 1.0a allowed any client-specific parameter in the callback.
The argument for adding a state parameter was to increase interop but
that is only true if it comes instead of custom parameters.
EHL
On 4/9/10 7:37 AM, "Evan Gilbert" <uid...@google.com> wrote:
On Fri, Apr 9, 2010 at 12:32 AM, Eran Hammer-Lahav
<e...@hueniverse.com> wrote:
On 4/8/10 11:11 PM, "Evan Gilbert" <uid...@google.com> wrote:
>>
>>
>>>> 2. Section 2.1: "The authorization endpoint advertised by
the server
>>>> MUST NOT include a query or fragment components as defined by
>>>> [RFC3986] section 3." Why do we disallow query parameters?
If we want
>>>> to enforce strict matching of callback URLs maybe we
should just
>>>> demand that.
>>>
>>> I don't like having both custom query and a state
parameter. If servers have
>>> to accommodate custom queries, then we might as well drop
the special state
>>> parameter since clients can just make up whatever they
want. I opted to use
>>> the state parameter because it makes pre-registering URIs
easier, and it
>>> doesn't cause parameter namepsace conflicts (which is still
an open issue).
>>
>> I think I got mixed up a bit. The authorization server endpoints
>> should be allowed to have query parameters. No state is
passed through
>> these, and also no matching done against them.
>>
>> Registered callback URLs for clients should also be allowed
to have
>> query parameters. If strict matching is enforced, at least
for the
>> query part, then no state that can be passed, so they have
to use the
>> state parameter. Parameter namespace can be an issue, one
more reason
>> to keep the prefix :-)
>
> +1 on callback URLs and authorization server being allowed to
have query
> parameters.
Nothing in the spec prevents the authorization endpoint from
including
extensions. Right now the spec is silent on how extensions
work which means
the server developer has to be careful in adding new
parameters and should
probably prefix them with their company name or some other
prefix to ensure
they will not conflict with the core parameters and standard
extensions. I
also rather make it less appealing to extend the authorization
endpoint
because each such custom extension (not published as a
standard) reduces
interoperability.
Callback URIs support client state which accomplishes
*exactly* the same
thing, but with full and trivial client support. So the
feature is there,
now we are just arguing over style.
> Callback URLs might be a page on an existing web site, and we
will be limiting
> the usefulness of the Web & User-Agent profile if we disallow
these pages to
> have query parameters.
Its trivial to add an endpoint that takes a callback and
redirects it
internally to the existing endpoint.
Not trivial to do this. That callback adds latency and more
importantly requires all clients do the proper redirect URL
enforcement. Proper redirect enforcement is an essential security
characteristic, and a small bug in URL parsing means that you've
created an open redirector (for example, checking that the URL
prefix is "http://www.mysite.com"; would be a bug, because
attackers could use "http://www.mysite.com:passw...@www.evil.com/";.
What is the benefit we get from the restriction on callback URL
parameters? It's not clear to me why we want this restriction in
the first place.
> Authorization server is probably less necessary, but don't
see any good reason
> to restrict.
Its not.
EHL
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
