Problem with [EnumMember] when using JsonStringEnumConverter

[JeroenVinke]

The JsonStringEnumConverter does not and will not support [EnumMember] attributes. So when you use the JsonStringEnumConverter globally in your project, the enum's in fido2-net-lib's models can not correctly be serialized/deserialized. This is not a problem when using Newtonsoft.Json, but are hitting this issue because we are converting projects from Newtonsoft.Json to only use System.Text.Json.

To support this use case, in .NET 9 Microsoft has introduced the [JsonStringEnumMemberName] attribute.

When fido2-net-lib supports .NET 9 or higher, I would like to propose to add the [JsonStringEnumMemberName] to all properties currently decorated with the [EnumMember] attribute, so that serialization/deserialization with the JsonStringEnumConverter works out of the box.

This problem was also mentioned in #594

Thank you for your efforts in building and maintaining this library. If necessary I can create a PR when the library has been updated to use .NET 9 or higher.

[abergs]

Please go ahead with a PR, it's always good to see the scope of the fix.

It would also be nice with a repro-example as I would expect this to be more widely reported.

[JeroenVinke]

Sure, I probably have some time next week to create a PR and repro. Thanks

[JeroenVinke]

This seems to be enough to reproduce the issue: JeroenVinke@a508f41. When you look at the response from the API you can see that the EnumMember attribute get ignored and the fido ceremony breaks in the frontend.

I have also made a quick and dirty attempt to fix the problem by adding the JsonStringEnumMemberName: JeroenVinke@6f0f404

Unfortunately this does not resolve the problem entirely, because the Algorithm.COSE enum should be serialized to integers, and not their enum member name.

I wonder if a better way to resolve this would be to provide JsonConverter's for types commonly used, such as AuthenticatorAttestationRawResponse and AuthenticatorAssertionRawResponseConverter.

That way, any serializer options defined on application level would not impact how Fido models are serialized/deserialized. What are your thoughts?

public class AuthenticatorAttestationRawResponseConverter : JsonConverter<AuthenticatorAttestationRawResponse>
{
    private readonly JsonSerializerOptions serializerOptions = new();

    public override AuthenticatorAttestationRawResponse Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options)
        => JsonSerializer.Deserialize<AuthenticatorAttestationRawResponse>(ref reader, this.serializerOptions)!;

    public override void Write(Utf8JsonWriter writer, AuthenticatorAttestationRawResponse value, JsonSerializerOptions options)
        => JsonSerializer.Serialize(writer, value, this.serializerOptions);
}

[iamcarbon]

.NET 8 is also going to be end of life in November. We could consider bumping to .NET 10 for v5, and dropping our custom serializer.

[lacutah]

I can vouch this can be a real headache - hard to troubleshoot and discover the underlying reason in a .net 10 project with system.text.json and an existing site-wide JsonStringEnumConverter. I spent way too much time troubleshooting why the server wasn't data-binding the Fido2 models from client requests before stumbling on this clue about where it was (silently and without error) failing.

[abergs]

I agree @iamcarbon

[vpetrusevici]

I tried. not sure if didn't miss anything #651

[vpetrusevici]

Hi @abergs,
Are you planning some release or beta version?

[abergs]

@vpetrusevici Yes in fact 5.0.0-preview.1 is already released and contains a fix for this (among other changes, see the change log)