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

Justin Richer jricher at MIT.EDU
Sun Jun 29 02:57:32 UTC 2014

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
    return JWT with client preference
  if (request is for JWT):
    return JWT with server default
    return JSON

What have other implementations done here? Do you use HTTP content negotiation at all or just go with the registered field?

 — Justin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140628/3e481707/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140628/3e481707/attachment.asc>

More information about the Openid-specs-ab mailing list