We've gradually marked classes and methods as being internal and/or final. I think we've never really done that for the Security component. But it's never too late.

@fabpot if we make things internal in 5.1, can we make BC breaking changes in 5.3/5.4? The BC promise says "Classes that received the @final annotation after their first release are considered final in their next major version.", but it doesn't mention if the same applies to @internal. I'm guessing it does, so that means we have to postpone the cleanup till 6.1/7.0

Currently there's a limited way of implemented a custom Authentication level. Before this implementation is deprecated, can we provide a way to add your own? For reference, this package is using a custom trust resolver to get into a "need 2 factor code" authentication level: https://github.com/scheb/two-factor-bundle/blob/728b743c03560f7f0aff53599f33e7e2a99f6868/Security/Authentication/AuthenticationTrustResolver.php

When removing this class in the future, there's no (easy) way to not be fully authenticated with a "custom level".

Oh, that's interesting.

What I would love to do is introducing the concept of "level of assurance" as described in #28868 (comment) . This would fully replace the IS_AUTHENTICATED_* attributes and provide a flexible alternative for build-in 2FA, sudo mode, etc.

Yet, I don't know about anyone working on that and I for sure don't have time to work on it atm. So I think the best option would be to postpone this PR and deprecated the AuthenticationTrustResolver if (when?) we implement level of assurance.

@wouterj What's your thoughts about this one? Shall we close?

Yes, let's close. At least at this moment, we can't remove the class (due to MFA usages). Sorry for not checking my stale PRs every so often!