You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 25, 2024. It is now read-only.
One of the core components of being able to use this library is storing registrations that are linked to the user for subsequent attempts to authenticate. As of now, this is a manual process requiring various manual format shifts to and from permanent storage. In addition to being complex and potentially error-prone, it could lead to situations where additional data needs to be introduced and cannot be reliably inferred from manual reconstruction.
include all of the data currently associated with Registration as of the time of writing (key handle, counter, public key, attestation certificate)
From a project implementor's perspective, persisted registrations could be migrated to (user_id, serialized_registration) instead of the current suggestion of (user_id, counter, key_handle, public_key, attestation_certificate) (though it may be valuable to include key_handle in its own column regardless; that doesn't impact the implementation).
It may also be worth providing a mechanism, or at least a recommendation, about signing and/or encrypting the data to reduce the risk of tampering.
The text was updated successfully, but these errors were encountered:
One of the core components of being able to use this library is storing registrations that are linked to the user for subsequent attempts to authenticate. As of now, this is a manual process requiring various manual format shifts to and from permanent storage. In addition to being complex and potentially error-prone, it could lead to situations where additional data needs to be introduced and cannot be reliably inferred from manual reconstruction.
There are numerous technical options here:
__sleep()
/__wakeup()
(limited functionality)Serializable
(deprecated in 8.1)__serialize()
/__unserialize
(>= 7.4 only)JsonSerializable
(no decode counterpart)Regardless of the mechanism, the format should:
From a project implementor's perspective, persisted registrations could be migrated to
(user_id, serialized_registration)
instead of the current suggestion of(user_id, counter, key_handle, public_key, attestation_certificate)
(though it may be valuable to include key_handle in its own column regardless; that doesn't impact the implementation).It may also be worth providing a mechanism, or at least a recommendation, about signing and/or encrypting the data to reduce the risk of tampering.
The text was updated successfully, but these errors were encountered: