Improve the touchpoints/API regarding the User class

[abergs]

There seem to some friction with mapping an applicationuser to the Fido2NetLib representation of a user.

From earlier discussion:

Problem

Given the current implementation, how can I extend the user class to include optional fields or add custom "additional user account attributes"? With generics, this would be easy.

Suggestion

Provide a constructor that accepts a generic TUser with a default of type User. TUser must inherit User.

Result of the Suggestion
This will have the effect that TUser must implement Idas as byte[]. Not many application users have this typing, so a 1:1 mapping is not probable. However an application could implement a custom fido2 TUser to carry more information than the current Fido2NetLib.User.

Question
Why would one want to extend the Fido2NetLib.User class? Is it for accessing more information in the Public delegate Task<bool> IsCredentialIdUniqueToUserAsyncDelegate(IsCredentialIdUniqueToUserParams credentialIdUserParams);?

Other thoughts
We should make sure that touchpoints are easy on the consumer. Mapping a custom Application user to a Fido2NetLib.User should at-least be as easy as possible. Perhaps by adding helper methods to convert expected fields of an Application User, such as string|guid|string Id to byte[]

[StillLearnin]

Good question. Two scenarios come to mind.

Complex or existing app with App.User class already in place.

This is the case for me. My preference would have been to extend Fido2.User with an AppUserId property.

Edit: Now that I've considered it farther, there is a mapping table that links App.User.Ids with external 0Auth provider keys from Facebook, Google, Microsoft, etc. so it would make sense to connect a Fido2.User that way as well.

Basic or new app

WebAuthn is the first and only type of authentication implemented. The developer wants to add a property or two without having to reference another table.

[StillLearnin]

We should make sure that touchpoints are easy on the consumer. Mapping a custom Application user to a Fido2NetLib.User should at-least be as easy as possible. Perhaps by adding helper methods to convert expected fields of an Application User, such as string|guid|string Id to byte[]

This sounds like a very good idea!

[Shtong]

I have a question regarding the initial problem : Does the Fido2 library deal with users, or does it deal with credentials ? In my mind, a library like this one should not bother providing a implementation for my users. It should provide a credentials entity, that is not linked to a "user" (whatever that may be), so that I am free to integrate these credentials in my app in any way I see fit. This is how other official credential providers, like Microsoft.AspNetCore.Authentication.Facebook, works.

Theorizing on this idea, you could have:

• One "core" library, that provides entities representing credential and other Fido2 data types, as well as tools to manipulate and verify them. Developers would link credentials with their users using integration rather than inheritance, which I think is much more flexible.
• Other optional, convenience libraries, that would make the core lib easier to use in the most common use cases. For example:
  • One to integrate with the ASP.NET Core identity model, linking the Fido2 credentials provided by the core with the users provided by ASP.NET.
  • Another Razor UI library that provides the Javascript tools useful for authentication, and even maybe UI elements like the Microsoft.AspNetCore.Identity.UI package does.

[StillLearnin]

@Shtong your ideas seem logical to me and a much better method of handling the problem than what I was originally proposing.