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.
> 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
