[Openid-specs-ab] When to return a JWT from UserInfo Endpoint?

John Bradley ve7jtb at ve7jtb.com
Sun Jun 29 21:55:58 UTC 2014

We didn't consider dynamic content negotiation on the user info endpoint to my recollection.   We assumed that registration would take care of it, if the client wanted something other than plain JSON then it would likely always want signed or encrypted.

Encrypted needs to be by configuration as you don't want an attacker overriding the option and defeating the reason for encryption. 

I can perhaps see an argument for dynamic signing, but in general wouldn't you always want it signed if you have the code to verify the response?

I don't see a reason to not allow content negotiation, as long as it doesn't result in downgrade attacks.   

John B.

On Jun 28, 2014, at 10:57 PM, Justin Richer <jricher at MIT.EDU> wrote:

> I ran into something when doing interop testing between MITREid Connect and Roland’s test framework: how is the server supposed to decide *when* to sign or encrypt the response from the UserInfo Endpoint as a JWT instead of a JSON object? We had requests from clients who want to be able to switch based on the Accept header, and so that’s how we originally implemented the decision logic. However, when doing interop testing with Roland, we found that his test client sent no Accept header at all, which confused our naive content negotiation. Even though we’ve now fixed that specific issue (made the header optional on the scanner, FWIW), I’m still scratching my head on this one:
> The specs give clients a mechanism for determining which algorithm to use via userinfo_signed_response_alg and the like, but should a client be able to request a JSON object through a request “Accept” header instead (which is much more HTTP-ish)? In which case, could a client with no registered userinfo_signed_response_alg ask for a signed object through an “Accept” header and take whatever signing mechanism the server deems reasonable as a default, just like what happens with the ID Token? 
> The way I’m leaning is logic basically like the following:
> if (client has preferred sign/encrypt algorithm):
>   if (request is for JSON):
>     return JSON
>   else:
>     return JWT with client preference
> else:
>   if (request is for JWT):
>     return JWT with server default
>   else:
>     return JSON
> What have other implementations done here? Do you use HTTP content negotiation at all or just go with the registered field?
>  — Justin
> _______________________________________________
> 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/20140629/5cd897b3/attachment.html>

More information about the Openid-specs-ab mailing list