Yes, you will need to store the flags. This will break for everyone who doesn't have backup eligible authenticators.

See here for more info: https://www.w3.org/TR/webauthn-3/#sctn-credential-backup

Looking at the way you're using this we can probably simplify this with tooling from the go-webauthn side, the binary value of the flags is already available so you don't need to convert it, but we can add a convenience method to derive the flags when reconstructing the credential. Let me know if this is preferable?

we can probably simplify this with tooling from the go-webauthn side, the binary value of the flags is already available so you don't need to convert it, but we can add a convenience method to derive the flags when reconstructing the credential. Let me know if this is preferable?

If there could be a simple and compatible (backward&forward) solution, it definitely helps a lot. Indeed as a library downstream, I think the fewer details the downstream knows, the more robust the system is. Thank you very much!

Inspect the change in go-webauthn/webauthn#337 and see what you think. I still need to update the docs and will do that time permitting. It's worthwhile to note that I plan on releasing soon but have one other fix I'd like to merge first. It adds an additional field which you should just backup Flags.Raw which can restore the whole of the Flags field with webauthn.NewCredentialFlags()

Also it's worth noting I personally recommend storing the credential attestation (field named Attestation), using json encoding to a TEXT/BYTEA column. I personally also encrypt it in all of my implementations as well as the pub key to avoid database tampering, but depends on your tooling if this is practical.

You don't need to restore it each time, but it will allow you to validate the attestation at a later date if you decide to leverage metadata. I can also provide some fairly decent recommendations on how to handle this, though you can also expect that the recommendations will make their way into the library as well.

Inspect the change in go-webauthn/webauthn#337 and see what you think. I still need to update the docs and will do that time permitting. It's worthwhile to note that I plan on releasing soon but have one other fix I'd like to merge first. It adds an additional field which you should just backup Flags.Raw which can restore the whole of the Flags field with webauthn.NewCredentialFlags()

Also it's worth noting I personally recommend storing the credential attestation (field named Attestation), using json encoding to a TEXT/BYTEA column. I personally also encrypt it in all of my implementations as well as the pub key to avoid database tampering, but depends on your tooling if this is practical.

You don't need to restore it each time, but it will allow you to validate the attestation at a later date if you decide to leverage metadata. I can also provide some fairly decent recommendations on how to handle this, though you can also expect that the recommendations will make their way into the library as well.

Thank you very much. After reading the code, I think maybe the current struct types are enough. We could just json encode/decode the flags.

Still a question in my mind, how could we recover the existing users without flags correctly? Should "setting BackupEligible=true" for them be enough?

Still a question in my mind, how could we recover the existing users without flags correctly? Should "setting BackupEligible=true" for them be enough?

If I understand the issue correctly you're wondering how to deal with previously stored credentials that may be in a state that is not serviceable. In theory the best option here would be to use a default value for the relevant column of NULL, and if it's NULL you add intermediary logic to automatically add the values during the login phase.

If my recollection is correct before you validate the login you can see the challenge response from the authenticator where you can copy those values. If you need help finding that let me know and I'll take a look in about 12 hours.

Effective steps:

1. Add the column(s) with default values of NULL.
2. If the columns are NULL:
   1. During a login copy the values from the challenge.
   2. Store the values in the database with an UPDATE.

In theory the best option here would be to use a default value for the relevant column of NULL, and if it's NULL you add intermediary logic to automatically add the values during the login phase.

Then what this PR did is not right .......

During a login copy the values from the challenge.

Maybe the last question: how to get the flags value from the challenge? I am not familiar with the code base and haven't figure out the key point to get the flags from the login request.

Hmm, get it from protocol.ParseCredentialRequestResponse => parsedResponse.Response.AuthenticatorData.Flags, is it right?

Hmm, get it from protocol.ParseCredentialRequestResponse => parsedResponse.Response.AuthenticatorData.Flags, is it right?

That's correct.

Thank you for your help, finally I think I somewhat could understand the details now.

Now we have 2 commits:

• c5a32f4 revert unnecessary changes and make some necessary preparations, not that important
• 5eeac46 !!the key change!! use the default authenticator flags when login, also added some comments there

I think we could resolve the problem now (the same behavior as webauthn 0.10), and leave the database migration to another PR (or if it doesn't really cause security problem, maybe we could just keep using the authenticator auth flags without really storing them?)