Userinfo response should be a jwt. OP's should support UserInfo JWT response

[Ralph Bragg]

OpenID Connect core details how the userinfo endpoint responses can be provided as either a JSON payload or a JWT depending on the accept headers on the GET request.

If a FAPI profile is being used to provide Identity Information then OPs should certainly be providing the UserInfo endpoint as a signed JWT.

Suggest adding this to the next implementors draft.

[Filip Skokan]

Unlike JWT Introspection the userinfo JWT from Core does not care about the Accept header but only the userinfo signing and encryption alg metadata on the client. When supported and set the response is always a JWT.

My first feedback to Torsten was suggesting to align that functionality in the introspection draft.

[Brian Campbell]

As Filip pointed out, for better or worse, the format of the UserInfo response it based on the client's userinfo_signed_response_alg, userinfo_encrypted_response_alg, & userinfo_encrypted_response_enc metadata rather than the accept headers.

But what problem would be solved or what value added by having FAPI say OPs should be providing the UserInfo endpoint as a signed JWT?

[Ralph Bragg]

The issue is really one of understanding around what FAPI is. The australians recently released a position paper where they called out that FAPI means "everything is signed and optionally encrypted". They included the UserInfo response payload in the list of items.

I wasn't aware until I re-read the underlying that a signed JWT was a possible response but i know that the majority of vendors don't support it.

This ticket is raised a discussion item. Does FAPI RW care if these isn't signed? Is there really a strong requirement for non-rupidation of identity claims post initial logon that could be provided by the ID Token.

If the UserInfo endpoint was used as a means of KYC/AML conveyance between OP and RP then arguably the RP would want this to be signed for non-repudiation purposes. FAPI RW doesn't really tackle PSU identity in any way. Should it?

[Takahiko Kawasaki]

Just FYI. Authlete supports userinfo_signed_response_alg, userinfo_encrypted_response_alg and userinfo_encrypted_response_enc.

Note that the specification (OpenID Connect Dynamic Client Registration 1.0) does not explicitly prohibit "none" from being used as a signature algorithm. If userinfo_signed_response_alg is "none" (and userinfo_encrypted_response_alg is not set), an Unsecured JWS (RFC 7515, A.5.) will be returned. But I wouldn't be surprised even if there exist some implementations that don't allow "none", though.

If signed JWT is necessary, FAPI spec should explicitly prohibit Unsecured JWS.

[Dave Tonge]

@RaidiamRalph what do you want to do with this ticket? Personally I don't think we should address the userinfo endpoint in FAPI.

[Nat Sakimura]

@Ralph Bragg Could you update us on this ticket?

[Ralph Bragg]

The requirement for FAPI to try and address this as has long passed. Unfortunately none of the banks in the UK took up seriously using Open Banking as an opportunity to become identity providers. I still think that a signed identity response payload when used for identity verification has significant value over an unsigned blob but it is perhaps now best to leave this to the eKYC working group.

Happy to close

[Dave Tonge]

We agreed not to deal with this in FAPI