Yes the was the intent. On 2013-08-22, at 1:38 PM, Justin Richer <jric...@mitre.org> 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? >> 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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
