(Un-)linking and updating credentials and their identifiers

[aeneasr]

Is your feature request related to a problem? Please describe.

At some point in the lifecycle of an identity, credentials might be added, removed, or updated:

• A user wants to link, in addition to the current "sign in with google", his/her github account for use of login.
• A user wants to link, in addition to password method, his/her github account for use of login.
• A user wants to unlink his/her github account
• A user wants to add a passwordless (email code, sms code, magic link) login
• A user wants to update the email address used for login (with password or passwordless)
• A user wants to update the password used for login

Describe the solution you'd like

All of these flows require user presence. This means that the user must have completed an authentication process within a reasonably short period of time prior (e.g. 5 minutes) to performing this flow. This could be solved in kratos internally by using the "AuthenticatedAt" field from the session.

Describe alternatives you've considered

Auth0 has a guide on user account linking: https://auth0.com/docs/link-accounts

Additional context

We need to respect #119

[aeneasr]

One approach taken by Google Account when updating credentials is to:

1. Redirect the UA to a URL like /updatepassword
2. The server at /updatepassword checks if a verifier is set (rapt):
3. If no rapt is set, the user is redirected to the login ui with a challenge rart (continue 3)
4. If rapt is set and can be verified (user from session equals user from rapt, request is not expired, contains maybe a signed variant of rapt?), the ui is shown. If the rapt can not be verified a new challenge rart is computed (using info from the authenticated session) and the user is redirected to the login url.

If the user is not authenticated at all, calling /updatepassword will show a screen with a "login button". I think we could redirect to login and compute a rart with an empty subject?

---

In conclusion, this approach is much safer than what Auth0 is doing, as they do not require proof of authentication before updating/changing

[aeneasr]

This is already implemented except for OIDC which is tracked as #32