Re: [OAUTH-WG] Authz Header + client_id in message body

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" <torsten@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 <ve7jtb@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 <torsten@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
>> > https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
>