With Fido keys you are really supposed to be registering another key and using it to login and replace this key if it is lost or damaged. So they are probably going out of their way to block backups.
AFAIK, (though I haven't looked at newer protocol versions) if you somehow had an original backup of the token state, it would be all that you need for normal auth aside from setting a high enough counter value since the RP (website) should be providing the opaque key from the registration.
In situations where there are resident keys it would do no good to save them if the token context itself can not be backed up and is lost. I'm not sure that really matters though since this project seems to only work between browsers so I don't see how you could use this kind of virtual key with ssh, OS services, etc, that might not store the opaque key normally.
AFAIK, (though I haven't looked at newer protocol versions) if you somehow had an original backup of the token state, it would be all that you need for normal auth aside from setting a high enough counter value since the RP (website) should be providing the opaque key from the registration.
In situations where there are resident keys it would do no good to save them if the token context itself can not be backed up and is lost. I'm not sure that really matters though since this project seems to only work between browsers so I don't see how you could use this kind of virtual key with ssh, OS services, etc, that might not store the opaque key normally.