-
-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve the touchpoints/API regarding the User class #88
Comments
Good question. Two scenarios come to mind. Complex or existing app with
|
This sounds like a very good idea! |
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:
|
@Shtong your ideas seem logical to me and a much better method of handling the problem than what I was originally proposing. |
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
Id
as 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
tobyte[]
The text was updated successfully, but these errors were encountered: