Open HowardWolosky opened 3 years ago
Ha, what an interesting idea! I like it!
Question: does this necessarily presuppose / imply solving the NASCAR flag problem or are you suggesting this can be done even in the absence of a cross IDP account chooser (i.e. Host OS accounts available for a specific IDP)?
NASCAR should only be a fallback. The RP should be able to invoke CredMan with a list of supported IdPs and DID methods. The browser can check its internal account cache, query wallets and query the OS.
FederatedCredential
in the CredMan API already essentially provides that capability, but has failed to gain adoption (and correspondingly, universal browser implementation). It might be useful to explore why that is the case.
Agree, RPs will want to have choice and send users to a specific IDP/Auth method. A lot of them are using identity first flows increasingly to guide user to login options.
@kenrb , NASCAR is the norm for implementors and consumers so there really hasn't been a push to leverage CredMan. With a big change like the browser brokering identity, now is the time to leverage this. We'd add DID methods and VCs to CredMan as part of this.
Many user agents/web browsers allow a user to associate a federated identity with their browser profile, and some host operating systems allow 1+ federated identities to be associated with the user's account and shared with installed applications.
It would be beneficial if WebID allowed for the promotion of those identities known by the UA and host OS to WebID as selectable identities within its login form, without requiring the user to reenter those credentials.
Additionally, if WebID does allow for the promotion of these preexisting identities to be promoted to the login form, it would follow that we should provide the ability for users to choose if new identities that they authenticate with via WebID should be saved back to the UA (if the profile allows for it) or the host OS (if the federated login type is supported).