FAPI-RW: Is disallowing signed id_tokens allowed? (i.e. always used signed+encrypted)

[Joseph Heenan]

https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md#markdown-header-5221-id-token-as-detached-signature reads:

shall support signed ID Tokens;

should support signed and encrypted ID Tokens;

I’m not sure whether to read this as “must support either JWS or JWE id_tokens”, or if it’s “must support JWS and may support JWE”.

i.e. can authorization servers opt to always use encryption?

‌

Naively I can’t see any reason to rule out going all-in on encryption, unless it’s for interoperability reasons. (and if it is for interoperability, it might be worth adding a note to that effect.)

‌

[Stuart Low]

I can see justifications either way, probably the biggest concern I have with allowing exclusively signed & encrypted is that it appears to drop the available client implementations from 15 to 6 at this point. Doing a rudimentary look through the available client implementations requiring JWE support makes libraries available only for C/C++, Haskell, Java, Apache CXF and NodeJS. By comparison there are JWS implementations in C/C++, ASP.NET, .NET 4.5, .NET 3.5+, OWIN (.NET), Haskell, Apache CXF, Java & NodeJS.

Essentially it seems JWE support is entirely absent from the .NET ecosystem?

‌

[Freddi Gyara]

The OBIE directory does not have the ability to provide enc keys on its JWKS.

OBIE standard does not expect any user identifiable data in the `id_token` - in such situations encrypting rather than signing would be overkill.

[Stuart Low]

@Freddi Gyara Neither does CDS but the point of this ticket was really around the specific FAPI wording regarding whether an implementation can be classified as passing certification if it was to implement ONLY Signed & Encrypted.

[Joseph Heenan]

It was clarified on the call this week that supporting only JWE is an acceptable option, and supporting only JWS is also fine [but not recommended if there’s an PII]. The decision as to whether one or both is permitted is upto the ecosystem or authorization server. I suspect we need to tweak the spec wording to make that clear, as it’s currently possible to read it as saying that supports JWS (unencrypted) is mandatory.

[Tom Jones]

That last statement is even more confusing. The internet standard has always been to be strict on outbound, but forgiving on inbound. It seems that making receipt of JWS tokens mandatory for conformance tests should be required even if sending them is optional. What happens at the application layer may, of course, be different.

[Joseph Heenan]

It seems that making receipt of JWS tokens mandatory for conformance tests should be required even if sending them is optional.

The conformance tests have to be able to run against live deployments. If ecosystems are permitted to say that they won’t allow signed-but-not-encrypted id_tokens to be returned (and will instead only allow signed-and-encrypted), then the conformance suites have to accept signed-and-encrypted tokens.

[Tom Jones]

From an open id perspective that statement is demonstrably false. When I got rp certification I had to add features to my program to pass the tests that were disabled after testing was completed.

[Joseph Heenan]

Yes, that’s the case for the OpenID Connect certification test.

‌

It is not true for the FAPI tests which are run against production systems of banks and used as evidence to show compliance to their National Competent Authority; we cannot insist a bank makes temporary changes to a production system just to pass certification, particularly not when those changes would reduce security.

The aim of the certification is not only to show that the bank is using compliant software, but that they have correctly configured that software.

(The majority of problems the banks find when running certification tests against production is invalid configuration.)

[Ralph Bragg]

@Freddi Gyara The OBIE directory does indeed support ENC keys, i added them precisely for id_token encryption support. encrypted ID token support has been available since mid 2019. Addressing the ticket, I was campaigning to allow sign id_tokens to be used instead of encrypted as part of the draft. So it was meant to be interpreted, in my opinion, as an AWS Must support Signed id_tokens and it can choose to support encrypted id_tokens.

I personally wouldn’t have an issue if a bank mandated encrypted id_token support.

‌

[Nat Sakimura]

The downside of mandating Encrypted Token: makes it complicated. The downside of just allowing signed token: PII may be exposed.

Maybe we should add to the privacy consideration on the above.

[Dima Postnikov]

Current AU CDR standard:  In accordance with [FAPI-RW], ID Tokens must be signed and encrypted when returned to a Data Recipient from both the Authorisation End Point and Token End Point.

[Dima Postnikov]

And… The ID Token returned from the Authorisation End Point MUST NOT contain any Personal Information (PI) claims.

But it does contain sub value as a Pairwise Pseudonymous Identifier

[Joseph Heenan]

shall support signed ID Tokens;

could be changed to require the AS:

shall support signed ID (or signed and encrypted) id tokens;

‌

[Joseph Heenan]

we likely need to alter this clause on clients as well:

should require both JWS signed and JWE encrypted ID Tokens to be returned from endpoints to protect any sensitive personally identifiable information (PII) contained in the ID Token provided as a detached signature in the authorization response.

‌

[Dave Tonge]

Dave to prepare PR with requirements on RPs to support encrypted id tokens

[Dave Tonge]

https://bitbucket.org/openid/fapi/pull-requests/179/claify-requirement-for-clients-to-support

[Dave Tonge]

PR merged