Yes the was the intent.
On 2013-08-22, at 1:38 PM, Justin Richer wrote:
> +1, I believe that was the intent of the edit.
>
> -- Justin
>
> On 08/22/2013 01:33 PM, Brian Campbell wrote:
>> I so believe that was the intent and what it probably should have said. So
>> maybe errata makes sense?
+1, I believe that was the intent of the edit.
-- Justin
On 08/22/2013 01:33 PM, Brian Campbell wrote:
I so believe that was the intent and what it probably should have
said. So maybe errata makes sense?
On Aug 17, 2013 12:15 PM, "Torsten Lodderstedt"
mailto:tors...@lodderstedt.net>> wrot
I so believe that was the intent and what it probably should have said. So
maybe errata makes sense?
On Aug 17, 2013 12:15 PM, "Torsten Lodderstedt"
wrote:
> Hi all,
>
> would it make sense to issue an errata and add a "public" to the sentence
> as follows?
>
> "A _public_ client MAY use the "cl
Hi all,
would it make sense to issue an errata and add a "public" to the
sentence as follows?
"A _public_ client MAY use the "client_id" request parameter to identify
itself
when sending requests to the token endpoint."
regards,
Torsten.
Am 01.08.2013 15:57, schrieb Brian Campbell:
I th
I thought I remembered that text from RFC 6749, section 3.1 as saying that
a *public* client MAY use the "client_id" request parameter to identify
itself...
Apparently that's not what it says. But I believe that was the intent - hat
a client with no means of authentication could identify itself by
Hmm allowing sending the client_id even if there is no authentication was
intended to mitigate cases where the client presenting the code or
refresh_token was not the one that requested it, and for logging.
I don't think the intention was to allow the client_id to be sent twice.
If it were my
