+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"
<tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> 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 "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 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 sending only the "client_id" request parameter
to the token endpoint.
Sec 2.3 (http://tools.ietf.org/html/rfc6749#section-2.3) says,
"The client MUST NOT use more than one authentication method in
each request."
And 5.2 (http://tools.ietf.org/html/rfc6749#section-5.2) has
"invalid_request
The request is missing a required parameter,
includes an
unsupported parameter value (other than grant type),
repeats a parameter,*includes multiple credentials,*
utilizes more than one mechanism for
authenticating the
client, or is otherwise malformed."
There is some room for ambiguity in all that but, based on the
above, I'd say that the way your server is behaving is correct
Torsten.
On Thu, Aug 1, 2013 at 2:13 PM, John Bradley <ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>> wrote:
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 Token endpoint I would ignore the extra one and
only processes the one sent as part of the authentication,
if there is no authentication then the value of the
"client_id" parameter MUST match the client_id that was used
to request the token.
It is probably a open question if the request should be
considered malformed if it contains both.
Personally I would recommend that the client not do that.
Others may remember it differently.
John B.
On 2013-08-01, at 11:34 AM, Torsten Lodderstedt
<tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> wrote:
> Hi,
>
> while setting up our OIDC interop tests, we run into the
following problem:
>
> The test client sends a request to the token endpoint,
which contains the client credentials in an authorization
header. Additionally, it adds the client_id to the message
body. Our server treats this as an invalid request and
responds with HTTP status code 400.
>
> Now my question: The last paragraph of RFC 6749, section
3.1 (http://tools.ietf.org/html/rfc6749#section-3.2.1) states
>
> "A client MAY use the "client_id" request parameter to
identify itself
> when sending requests to the token endpoint."
>
> This seems to allow the client to send the client_id in
addition to any other credential used to authenticate it.
>
> I'm not sure what the intension is/was. How is the server
supposed to handle such cases? Shall it compare both ids
(from the header and the body)? Must they match exactly?
>
> Any feedback is appreciated.
>
> regards,
> Torsten.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
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
