Mention complementary security standards (OAuth mTLS, etc)

[Vladimir Dzhuvinov]

In a informal talk about IdA I mentioned that given the nature of the standard and the personal data it deals with, providers should require strong client authentication and client certificate-bound access tokens (mTLS) for the UserInfo endpoint.

I suppose it makes sense to mention this together with the applicable specs in a section at the bottom of the spec.

I’m not sure if this should be normative or just informational.

[Torsten Lodderstedt]

Shall we add a link between identity and authentication assurance?
Shall we add link between identity and assertion binding (800-63 C) (FAPI?)

[Torsten Lodderstedt]

I’m in favour of adding an informal reference to FAPI as security profile.

[Torsten Lodderstedt]

I think FAPI 2 baseline is an obvious candidate as it provides suitable security and additionally robustness through PAR. eKYC use of the claims parameter causes large authz requests, so PAR would be a good complementary mechanism.

[Mark Haine]

Should there be a security profile fo eKYC?

Choices that could be taken

1. FAPI 1.0
2. FAPI 2.0
3. a ‘simplified FAPI’
4. a special eKYC security profile
5. something else
6. Nothing in the spec and left up to implementers?

‌

[Mark Haine]

I think using something existing is best in order to keep implementations consistent. It would also help with conformance testing if it was re-useing tests that do (or will) exist.

[Alberto Pulido Moyano]

In my honest opinion, we would really get benefit and help industry adoption by providing an ad-hoc security standard.

The main reason for me, is to take into account that by sharing verified claims along, many business applications can build very strong propositions for their customers. I mean, there is no need to protect or access other resources after getting the claims in id_token/user_info format.

My choice will be for option 4, but heavily influenced by FAPI.

‌

[Joseph Heenan]

It’s an interesting discussion and the answer is not clear to me.

There is currently pretty wide vendor support for FAPI-RW 1.0. PAR is one of the options available in FAPI-RW 1.0 (though vendor support for PAR is more lacking, having said that at least a couple of the major vendors support it).

The downside for FAPI-RW 1.0 with PAR is that it’s a bit trickier for RPs to implement than FAPI 2.0. The downside with FAPI 2.0 is that it’s still very new and has had less security analysis than FAPI 1.0.

I’m not in favour of a custom eKYC security profile unless there’s a really strong reason/advantage to doing so - a custom profile is likely to be trickier for RPs and OPs than picking FAPI-RW 1.0 unless done with great care. Alberto’s observation that many (all?) eKYC solutions might only issue very short lived access may be a strong reason, potentially implying you could avoid the complication of binding access tokens to TLS clients certificates. Though I think the eKYC spec as it currently is does potentially allowed for long lived sessions if there are use cases where the RP has interest in receiving future updates to the shared info?

‌

[Anthony nadalin]

I’m not in favor of a special profile, i would say that FAPI 2 would be my choice as we have to wind up there evenyually as the FAPI 1.0 move off to 2.0

[Mark Haine]

For context

FAPI 1.0 part 1 and 2 and FAPI CIBA are expected to be put to final vote in the next month

FAPI 2.0 is a long way off being ready for an implementation and does not have a implementers draft approved yet.

[Torsten Lodderstedt]

I suggest to add text to the security considerations to point our to implementers the need to analyse their security requirements and pick an appropriate security profile.

[Torsten Lodderstedt]

PR #39

[Mark Haine]

resolved by PR #39