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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
