I find the text confusing regarding client auth. >> "A client MAY use the "client_id" request parameter to identify itself >> when sending requests to the token endpoint"
It seems to suggest client auth is optional due to the MAY when in fact it is just referring to the client_id identifier which is not authn. I fear many have missed this subtle distinction. Or did you really intend optionality for assertions? Phil On 2013-05-01, at 5:35, Brian Campbell <bcampb...@pingidentity.com> wrote: > Just trying to close the loop on this thread (six weeks later, sorry). New > drafts were published last month that (hopefully) have more clear text about > the treatment of client_id. And it's been removed from examples where it's > optional. > > http://www.ietf.org/mail-archive/web/oauth/current/msg11213.html > > > On Tue, Mar 19, 2013 at 4:22 AM, Sergey Beryozkin <sberyoz...@gmail.com> > wrote: >> Hi, >> >> Just one remark, the example in [1] shows "client_id"; IMHO it makes sense >> to clarify than in this context (where the assertion is used as a grant), it >> is optional as per: >> >> http://tools.ietf.org/html/rfc6749#section-3.2.1 >> >> "A client MAY use the "client_id" request parameter to identify itself >> when sending requests to the token endpoint" >> >> and otherwise >> >> http://tools.ietf.org/html/rfc6749#section-2.3 >> >> dictates how the client authentication is done. >> >> By the way, my reading of the main spec's section 2.3 tells me that the only >> time one would use only "client_id" in the form payload is when the client >> secret is empty or perhaps the client is not in the possession of the secret. >> >> Does it make sense to completely drop a "client_id" parameter in the example >> at [1] in the assertion draft and use an example with a Basic authentication >> instead ? >> >> Thanks, Sergey >> >> >> On 15/03/13 22:12, Brian Campbell wrote: >>> So currently the base assertion document defines scope as an HTTP >>> parameter on the access token request message when using an assertion as >>> a grant[1]. And that applies to both the SAML and JWT grants (perhaps >>> that needs to be more clear?). Also RFC 6749 defines the scope parameter >>> for the client credentials access token request[2], which similarly >>> applies to both SAML and JWT in the case of assertion client >>> authentication using the "client_credentials" grant type. >>> >>> [1] http://tools.ietf.org/html/draft-ietf-oauth-assertions-10#section-4.1 >>> [2] http://tools.ietf.org/html/rfc6749#section-4.4.1 >>> >>> >>> On Fri, Mar 15, 2013 at 3:43 PM, Lewis Adam-CAL022 >>> <adam.le...@motorolasolutions.com >>> <mailto:adam.le...@motorolasolutions.com>> wrote: >>> >>> Right ... thinking about this further I think the answer is "all of >>> the above." If the JWT is a grant type then as you say it needs a >>> scope param and optionally a client_id param. I argued for the >>> client_id param earlier since it could assist with HOK scenarios >>> once those further develop. >>> >>> But when the JWT is used as an AT then it will definitely require >>> the scope as a claim. >>> >>> So I change my argument to "both" :) >>> >>> adam >>> >>> -----Original Message----- >>> From: oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org> >>> [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] On >>> Behalf Of Sergey Beryozkin >>> Sent: Friday, March 15, 2013 4:31 PM >>> To: oauth@ietf.org <mailto:oauth@ietf.org> >>> Subject: Re: [OAUTH-WG] JWT grant_type and client_id >>> >>> Hi >>> On 15/03/13 20:40, Lewis Adam-CAL022 wrote: >>> > Hi John, >>> > >>> > I would like to argue that the scope should be a parameter in the >>> access >>> > token request message, the same as it is for the RO creds grant and >>> > client creds grant type. This would keep it consistent with the core >>> > OAuth grant types that talk directly to the token endpoint. >>> > >>> Assuming the assertion is acting as a grant, then it is indeed an access >>> token request message, so IMHO it makes sense to get an outbound scope >>> parameter optionally supported which I guess will imply that the client >>> id will also have to accompany it... >>> >>> Cheers, Sergey >>> >>> > Thoughts? >>> > >>> > adam >>> > >>> > *From:*John Bradley [mailto:ve7...@ve7jtb.com >>> <mailto:ve7...@ve7jtb.com>] >>> > *Sent:* Friday, March 15, 2013 12:10 PM >>> > *To:* Lewis Adam-CAL022 >>> > *Cc:* Brian Campbell; "WG <oauth@ietf.org >>> <mailto:oauth@ietf.org>>"@il06exr02.mot.com <http://il06exr02.mot.com> >>> > *Subject:* Re: [OAUTH-WG] JWT grant_type and client_id >>> > >>> > The spec is a touch vague on that. I think the scopes should be >>> in the >>> > assertion and the client can use the scopes outside the assertion to >>> > down-scope. >>> > >>> > Having a standard claim in JWT and SAML for passing scopes is >>> probably >>> > useful as part of a profile. >>> > >>> > John B. >>> > >>> > On 2013-03-14, at 8:47 PM, Lewis Adam-CAL022 >>> > <adam.le...@motorolasolutions.com >>> <mailto:adam.le...@motorolasolutions.com> >>> > <mailto:adam.le...@motorolasolutions.com >>> >>> <mailto:adam.le...@motorolasolutions.com>>> wrote: >>> > >>> > >>> > >>> > Hmmm, one more thought ... no scope?? The JWT is the grant, is it >>> assumed >>> > that the scope is conveyed as a claim within the token? Otherwise it >>> > would seem that it would require a scope. >>> > >>> > Thoughts? >>> > >>> > adam >>> > >>> > *From:*Brian Campbell [mailto:bcampb...@pingidentity.com >>> <mailto:bcampb...@pingidentity.com> >>> > <http://pingidentity.com>] >>> > *Sent:*Thursday, March 14, 2013 4:44 PM >>> > *To:*Lewis Adam-CAL022 >>> > *Cc:*Mike Jones; "WG <oauth@ietf.org <mailto:oauth@ietf.org> >>> > <mailto:oauth@ietf.org >>> <mailto:oauth@ietf.org>>>"@il06exr02.mot.com >>> <http://il06exr02.mot.com> <http://il06exr02.mot.com> >>> >>> > *Subject:*Re: [OAUTH-WG] JWT grant_type and client_id >>> > >>> > Yes, that is correct. >>> > >>> > I'm working on new revisions of the drafts that will hopefully >>> make that >>> > point more clear. >>> > >>> > On Thu, Mar 14, 2013 at 5:26 PM, Lewis Adam-CAL022 >>> > <adam.le...@motorolasolutions.com >>> <mailto:adam.le...@motorolasolutions.com> >>> > <mailto:adam.le...@motorolasolutions.com >>> >>> <mailto:adam.le...@motorolasolutions.com>>> wrote: >>> > >>> > Coming back to this... am I correct in that client_id is not >>> required? We are implementing this spec and want to make sure >>> that we are doing it right. By my understanding the only two >>> parameters that are required in the JWT grant type are >>> "urn:ietf:params:oauth:grant-type:jwt-bearer" and the assertion. >>> Is this correct? >>> > >>> > *From:*Mike Jones [mailto:michael.jo...@microsoft.com >>> <mailto:michael.jo...@microsoft.com> >>> > <mailto:michael.jo...@microsoft.com >>> <mailto:michael.jo...@microsoft.com>>] >>> > *Sent:*Monday, February 18, 2013 6:58 PM >>> > *To:*Lewis Adam-CAL022;oauth@ietf.org >>> <mailto:adam-cal022%3boa...@ietf.org> <mailto:oauth@ietf.org >>> >>> <mailto:oauth@ietf.org>>WG >>> > *Subject:*RE: JWT grant_type and client_id >>> > >>> > The client_id value and the access token value are independent. >>> > >>> > -- Mike >>> > >>> > *From:*oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org> >>> > <mailto:oauth-boun...@ietf.org >>> <mailto:oauth-boun...@ietf.org>>[mailto:oauth-boun...@ietf.org >>> >>> <mailto:oauth-boun...@ietf.org> >>> > <mailto:oauth-boun...@ietf.org >>> <mailto:oauth-boun...@ietf.org>>]*On Behalf Of*Lewis Adam-CAL022 >>> > *Sent:*Monday, February 18, 2013 2:50 PM >>> > *To:*oauth@ietf.org <mailto:oauth@ietf.org> >>> <mailto:oauth@ietf.org <mailto:oauth@ietf.org>>WG >>> >>> > *Subject:*[OAUTH-WG] JWT grant_type and client_id >>> > >>> > Is there any guidance on the usage of client_id when using the JWT >>> > assertion profile as a grant type? draft-ietf-oauth-jwt-bearer-04 >>> makes >>> > no mention so I assume that it is not required ... but it would be >>> > necessary if using in conjunction with a HOK profile where the JWT >>> > assertion is issued to - and may only be used by - the intended >>> client. >>> > Obviously this is straight forward enough, really I'm just >>> looking to be >>> > sure that I'm not missing anything. >>> > >>> > tx >>> > >>> > adam >>> > >>> > >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org >>> >>> <mailto:OAuth@ietf.org>> >>> > https://www.ietf.org/mailman/listinfo/oauth >>> > >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto: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 <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
