Re: [OAUTH-WG] Token Introspection and JWTs

[Vladimir Dzhuvinov <[e-mail]>]

On 28/02/18 09:48, Torsten Lodderstedt wrote:
> Hi all,
>
> I have an use case where I would like to return signed JWTs from the authorization server’s introspection endpoint. In this case, I would like to give the resource server evidence about the fact the AS minted the access token and is liable for its contents (verified person data used to create a qualified electronic signature).
>
> Although token introspection more or less provides the RS with the content of a JWT, RFC 7662 only supports plain JSON. I talked to Justin and his recommendation was to use use a  header “accept: application/jwt” to ask the AS for a signed JWT as response instead of "application/json“. We could do this but clearly it would be a proprietary solution. 
Justin's suggestion would be relatively easy to implement. The only
small downside I see is that it doesn't allow resource servers to choose
a crypto algorithm for the issued JWT, which has become the norm for
this kind of things in OAuth and OIDC.

> I would like to know whether anyone else has the same or similar requirements and whether it would make sense to specify an extension to RFC 7662 for JWT responses.
Because of the requirement for resource servers to authenticate (or
submit a token authz) when they make an introspection request, we let
them register as a client, using std client registration. In that case
to let an RS register preferred JWT algs for the introspection response
we could have parameters

introspection_response_signed_response_alg
introspection_response_encrypted_response_alg
introspection_response_encrypted_response_enc

(naming follows pattern for ID token and UserInfo algs)

Vladimir