Thanks for submitting a patch!

I have one reservation here, which doesn't have anything to do with the work you've done: Originally, there was a discussion about whether we should add an interface for passports (which is nothing more than a value object). I managed to convince people by saying "I want to refactor the UserInterface". Meanwhile, @chalasr has done an amazing job in refactoring the UserInterface in a backwards compatible way.

In other words: I think we maybe should deprecate the PassportInterface and remove it in 6.0. That would make adding a new passport interface invalid. I would like to see how other core team members now think about this (cc @nicolas-grekas and @weaverryan as you both were part of the original discussion about this).

I would keep PassportInterface.
I think we can expect quite a lot of implementations in userland apps and community bundles, there are already some so having an abstraction makes sense to me, and I prefer an interface over a base class.

About the proposed extension, I tend to think we'd better add those methods to PassportInterface (in a BC way, via @method at first).

(sorry for the close/reopen, messed up with my keyboard)

About the proposed extension, I tend to think we'd better add those methods to PassportInterface (in a BC way, via @method at first).

The more I think about this suggestion, the more I start to think it actually makes the most sense.

At the root of this (and why I think the methods do need to be part of the interface, somehow), I know that the 5.3 compatible authenticators in LexikJWTAuthenticationBundle and JWTTokenRefreshBundle are using the attribute API and right now neither implementation is really 100% type-safe (both will end up causing fatals if someone were to subclass and authenticate with a passport that doesn't have attributes, like the passport linked from SchebTwoFactorBundle).

So, maybe the better approach is to add the attribute methods to the main PassportInterface and move the actual implementation from the root Passport class into the PassportTrait. This way, any custom passports (like the one from SchebTwoFactorBundle) using the trait only has to worry about the attribute methods potentially not existing while they're supporting Symfony 5.3, as the upgrade to 5.4 would add them automatically.

The one from scheb/2fa actually predates passport attributes (Christian did lots of work back in 5.1 to integrate the new system, while attributes were added "only" in 5.2). The needs of the special passport are now replaced by using attributes and I'll open an issue in that repository about deprecating the custom passport.

I really don't see a need to customize the passport. It has 2 very generic methods to store data: either the data is important for authentication - stored in a badge; or the data is just transported - key-value store using attributes.

Makes sense :) Custom badges are a better extension point and removes the need for custom passports. Let's burninate it!

Closing as discussed, thanks for raising @mbabker!