ProjectPasskeys: passkey_assertion to be added in the ID_token

[maduvena]

Feature:
Though this is not directly related to the code revamp effort, This will be used by the Cedarling module / auditing / logging etc

[maduvena]

Description:
At the time of token revocation, the AS looks at certain policies and "data" to make a decision,
In the future, if we have some fraud detection mechanisms in place, that will also look at certain "data" (audit log) to flag the behaviour

So, essentially, at the time of login, we are trying to populate the ID_token with authentication method, and the credential that was used at the time of login.
The contents of the ID_token will be logged and that is the "data" being used by point 1 and 2.

In a real implementation of the janssen server, the user will be presented the option to enroll and use multiple credentials - for. e.g. the casa script

We want to move this part of "populating the ID token with these two amr fields - auth_method, cred_info" into the java side
a. so as to simplify it for the developer otherwise, he will have to do it in the script / agama code.
b. Mike is pushing for adoption agama which is sole-ly for Authentication journeys and not building ID_token, AT etc
c. agama language currently doesn't have the scope to populate AMR fields

Discussion
Whole authentication approach on AS side relies on PersonAuthenticationType script.
AS has only one built-in simple_password_auth authentication method (ldap authn configs are similar), all other things are externalized into custom authentication script.
Thus naturally everything related to specific custom script should be inside that script.
For example casa script should bring all related to casa details. agama script should bring all agama related details.
If it doesn't come from script then from where AS should take it? We can think on some entirely different approach if we don't want to use custom scripts.

With custom scripts we can use 2 approaches:

1. return claims in getAuthenticationMethodClaims method.
2. or otherwise if we don't want to use that method we can record data into session in authenticate method and later read it from session.

Both ways should work.

About renaming method in PersonAuthenticationType script. We can do it however it will broke all existing scripts.
All existing scripts would have to be updated. Thus we have to be really sure the benefit of renaming pays off maintenance caused by it.

3. There is only one bridge which inform jans-auth-server that user log in. We can add new methods to AuthenticationService for user authentication. And deprectate old methods and mark them for removal.

Mike's final comments
Regarding getAuthenticationMethodsClaims method, we could deprecate it, but let's make that decision later. It doesn't add a ton value to end users.
I've also come around to seeing the script as the right place to do this.
What this claim is called, and what goes into it are not standard... so it makes sense to make it visible how it is mapped.

However, we can ship out of the box with this code in the agama_bridge script... which will be the connector for most of the FIDO Web flows
Although, it won't address the FIDO mobile flow that originate from the authz_challenge endpoint.