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

John Bradley ve7jtb at ve7jtb.com
Tue Apr 3 16:25:49 UTC 2012


I think those scenarios are interesting for enterprise.   They probably are not going to be seen much on the open internet, as you still have the problem of authenticating the client to the STS.

It probably needs to be though through as an extension as there are several moving parts.

John B.
On 2012-04-03, at 1:05 PM, Brian Campbell wrote:

> 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.
>> prn
>> REQUIRED. The prn (principal) Claim. This MUST contain the client_id of the OAuth Client.
>> 
>> 
>> 
>> Thanks, talk to you shortly.
>> 
>> 
>> -- 
>> Pamela Dingle  |  Sr. Technical Architect
>> PingIdentity  |   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/dc0e11d4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4937 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120403/dc0e11d4/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list