[Openid-specs-ab] Possible typo on Client Authentication

Brian Campbell bcampbell at pingidentity.com
Tue Apr 3 16:05:50 UTC 2012


Yeah, that makes sense and I don't necessarily think a change is needed.
Responding to Pam's question was the first time I'd really considered that
implicit restriction and was more thinking out loud than anything.

FWIW, I was thinking about it as the case where the client talks directly
to the AS's Token Endpoint but might use an STS to get the JWT. My thinking
is probably somewhat biased by the product I build but there are some
situations where an STS holds all (most) of the key material and aggregates
the trust with other organizations.

On Tue, Apr 3, 2012 at 9:50 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> We are using the OAuth Assertion profile and JWT bearer token profile for
> Oauth.
> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-03
>
> In the case where the JWT is self issued by the client the iss and prn are
> both the client.
>
> You are correct that there may be cases where there is a intermediary in
> the general case of the Assertion profile.
> I however have a hard time seeing that as a issue when the client is
> talking to the Token Endpoint directly, as is required by OAuth.
>
> Anything like that is going to be extension territory.
>
> I could probably live thigh the iss SHOULD contain the client_id of the
> OAuth Client.   To allow for extension however I don't really want to start
> describing all of the possible acceptable permutations in the core specs.
>
> It starts looking more like WS* if we go down that route.
>
> I am inclined to levee it as it is currently and let an extension deal
> with the alternate scenarios.
>
> John B.
>
>
>
>
> On 2012-04-03, at 8:59 AM, Brian Campbell wrote:
>
> I believe that what is there is correct or at least what was intended.
> "iss" is the issuer of of the JWT to be used for client authentication. In
> this case it's saying that such JWTs are self issued.  Which makes sense
> and I think is what was intended (but don't know so someone please correct
> me, if I'm wrong).
>
> Is it potentially too restrictive though?  It would seem to presume that
> clients always have access to the keying material. That's likely the case
> most of the time but the text as written would seem to preclude a situation
> where a client might interact with an STS (that holds the key material) to
> obtain a JWT for client authentication.
>
>
> On Mon, Apr 2, 2012 at 3:53 PM, Pam Dingle <pdingle at pingidentity.com>wrote:
>
>> In section 2.2.1 of the Messages document (draft 08), in the Client
>> Authentication section, the iss and the prn elements both have identical
>> definitions, both containing the client_id of the OAuth Client.  Shouldn't
>> the issuer be the AS?
>>
>> Here is the text:
>>
>>
>> iss REQUIRED. The iss (issuer) Claim. This MUST contain the client_id of
>> the OAuth Client. prnREQUIRED. The prn (principal) Claim. This MUST
>> contain the client_id of the OAuth Client.
>>
>>
>> Thanks, talk to you shortly.
>>
>> --
>> *Pamela Dingle*  |  Sr. Technical Architect
>> *Ping**Identity*  |   www.pingidentity.com
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - - -
>> *O:* 303-999-5890   *M:* 303-999-5890
>> *Email:* pdingle at pingidentity.com
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - - -
>> *Connect with Ping*
>> Twitter: @pingidentity
>> LinkedIn Group: Ping's Identity Cloud
>> Facebook.com/pingidentitypage
>> *Connect with me*
>> Twitter: @pamelarosiedee
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120403/669eec6a/attachment.html>


More information about the Openid-specs-ab mailing list