Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release

From: Mike Jones <[email-masked]>
Date: Fri, 4 Jan 2013 22:35:14 +0000

There's no generic OAuth way to do this.  There is a way to do it in OpenID Connect - see request_object_signing_alg, userinfo_signed_response_alg, and id_token_signed_response_alg in http://openid.net/specs/openid-connect-registration-1_0-13.html#anchor3 and userinfo_signing_alg_values_supported, id_token_signing_alg_values_supported, and request_object_signing_alg_values_supported in http://openid.net/specs/openid-connect-discovery-1_0-11.html#anchor9.

                                                            -- Mike

From: William Mills [mailto:[email-masked]]
Sent: Friday, December 28, 2012 6:07 PM
To: Mike Jones; [email-masked]
Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release

Mike,

I've read through the JWT spec and I'm curious about something.  How do I specify a signature requirement as the server?  I didn't see it but I probably just missed it.  I'm thinking that with very little work a JWT can do everything that MAC does with greater flexibility, *BUT* the server needs to be able to require a signed usage.  Something I never liked about OAuth 1.0 is that the server must support all valid signature types, even PLAINTEXT, so I want to be able to avoid that.

It would require the client to be able to include client generated stuff in the JWT.

Thanks,

-bill

---

From: William Mills <[email-masked]>
Date: Fri, 4 Jan 2013 14:48:20 -0800 (PST)

It's the core problem I see MAC solving.  I'd be happy enough to define a JWT variant that does this if that's easier than MAC.  What do you think?

________________________________
 From: Mike Jones <[email-masked]>
To: William Mills <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Friday, January 4, 2013 2:35 PM
Subject: RE: [OAUTH-WG] December 27, 2012 OAuth Release

There’s no generic OAuth way to do this.  There is a way to do it in OpenID Connect – see request_object_signing_alg, userinfo_signed_response_alg, and id_token_signed_response_algin
http://openid.net/specs/openid-connect-registration-1_0-13.html#anchor3 and  userinfo_signing_alg_values_supported, id_token_signing_alg_values_supported, and request_object_signing_alg_values_supportedin
http://openid.net/specs/openid-connect-discovery-1_0-11.html#anchor9.
 
                                                            -- Mike
 
From:William Mills [mailto:[email-masked]] 
Sent: Friday, December 28, 2012 6:07 PM
To: Mike Jones; [email-masked]
Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release
 
Mike,

 
Thanks,
 
-bill

---

From: John Bradley <[email-masked]>
Date: Fri, 4 Jan 2013 20:44:26 -0300

If everything you want to sign can go in the JWT there is nothing to stop that.   Otherwise you are back to coming up with a way of doing a detached signature and putting a hash in the JWT like connect is doing by putting a hash of the token in the id_token for the "token id_token} flow.

The hard part is figuring out what needs to be signed.   

As for client generated JWT we already have the JWT assertion profile.  Connect is using that as an option to authenticate to the token endpoint. 

Would doing a similar thing but to the RS really work for you?

John B.
On 2013-01-04, at 7:48 PM, William Mills <[email-masked]> wrote:

> There’s no generic OAuth way to do this.  There is a way to do it in OpenID Connect – see request_object_signing_alg, userinfo_signed_response_alg, and id_token_signed_response_alg in http://openid.net/specs/openid-connect-registration-1_0-13.html#anchor3 and userinfo_signing_alg_values_supported, id_token_signing_alg_values_supported, and request_object_signing_alg_values_supported in http://openid.net/specs/openid-connect-discovery-1_0-11.html#anchor9.
>  
>                                                             -- Mike
>  
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: William Mills <[email-masked]>
Date: Fri, 4 Jan 2013 15:57:11 -0800 (PST)

Yeah, I think it would work. Adding client asserted JWT payload would also nicely get out of the whole question of where the nonce, timestamp, and such go and whether they can be part of the query string, which was always annoying with MAC and OAuth 1.

We still have the problem that some clients don't know what order the query or post arguments will be generated in, but that wasn't resolved yet anyway.

How do we solve for the server requiring a specific set of supported hashes and feeding that back to the client?

-bill

________________________________
 From: John Bradley <[email-masked]>
To: William Mills <[email-masked]> 
Cc: Mike Jones <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Friday, January 4, 2013 3:44 PM
Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release

John B.

---

From: John Bradley <[email-masked]>
Date: Fri, 4 Jan 2013 21:09:58 -0300

In the Connect case part of discovery is a JSON document in .well-known that describes the servers capabilities. 
Something similar might work.  There is nothing JWT specific about the connect document though we do specify the JWA set of algorithms and JWK for publishing keys.

John

---

From: William Mills <[email-masked]>
Date: Fri, 4 Jan 2013 21:55:47 -0800 (PST)

That would work.  Register a link relation property for supported signing methods.

Sent: Friday, January 4, 2013 4:09 PM

John