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