+1
2013/2/13 Torsten Lodderstedt :
>
> Am 12.02.2013 um 15:57 schrieb Justin Richer :
>
>>
>> I think that's a very important difference.
>
> I fully agree.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
--
Am 12.02.2013 um 15:57 schrieb Justin Richer :
>
> I think that's a very important difference.
I fully agree.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
So, I think we agree in general, but to be explicit: I want a server to
be free to include the client_id as an input parameter if it wants to,
but I would rather not have the client be required to compose that
parameter onto the base registration URL on its own. This is to preserve
the flexibil
On 12/02/13 14:43, Tim Bray wrote:
?! /foo and /foo/bar are obviously distinct endpoints.
definitely yes from the client's point of view, at the implementation
level - it is the internal detail, right ?
Cheers, Sergey
On Feb 12, 2013 3:25 AM, "Sergey Beryozkin" mailto:sberyoz...@gmail.co
It can be argued that /foo and /foo?provider=abc are different URI resources.
Nat and I were recommending that the registration return a update URI that can
be unique per client.
In the Apps for domains or Salesforce case the hosting client could be encoded
into the path or a parameter if req
Technically you could have your auth endpoint be:
/oauth?method=authorization
and your token endpoint be:
/oauth?method=token
and they're syntactically being served by the same URL. It's a
deep-in-the-weeds argument of little value whether or not you consider
these to be "separate endpoints"
?! /foo and /foo/bar are obviously distinct endpoints.
On Feb 12, 2013 3:25 AM, "Sergey Beryozkin" wrote:
> Hi Mike,
> On 12/02/13 01:26, Mike Jones wrote:
>
>> At most, there should be two endpoints - creation and management - for a
>> client, but the protocol should be structured such that they
Hi Mike,
On 12/02/13 01:26, Mike Jones wrote:
At most, there should be two endpoints - creation and management - for a client, but the protocol
should be structured such that they *can* be at the same URL, if the server so chooses. A simple
way to accomplish this is to require that the client_
Hi Mike,
why do you think the protocol should allow to have two endpoints on the same
URL? Even the core spec does not allow to map tokens and authorization endpoint
to the same URL.
Regards,
Torsten.
Am 12.02.2013 um 02:26 schrieb Mike Jones :
> At most, there should be two endpoints - creat
At most, there should be two endpoints - creation and management - for a
client, but the protocol should be structured such that they *can* be at the
same URL, if the server so chooses. A simple way to accomplish this is to
require that the client_id value be provided as an input parameter on u
10 matches
Mail list logo
