Hmm, the closest thing I saw to this is the "caBLE" cloud-assisted bluetooth. Reading more on this, it does not sound exactly like what I am seeking. It seems completely tied to the platform vendors and interactions over the internet.
I wish for a completely local mechanism where a phone with a hardware security module could act like a token via completely local communication with the browser, both for enrollment and later login with any relying parties. For general users, I do like the idea of being able to backup/restore the token seeds to allow replacement of hardware without manually re-enrolling redundant keys with all relying parties.
But, I don't see why the cloud-assist should interpose between the user agent and the security device, nor why a cloud-assist should interpose between the user agent and the relying party. How is this cloud-assist different than the other vendors like Duo and Okta, interposed in enterprise client login attempts and organizing MFA options which can include authenticator apps on phones?
I feel like platform vendor lock-in has been gratuitously introduced into this plan. Couldn't a token backup/restore service be offered to users without interposing anything new service between the phone-as-token, the user agent communicating with the token, and the relying party service? Or, couldn't the token standards be amended with some sort of web-of-trust concept to allow a token to announce additional peer/backup token keys during enrollment. so that one enrollment task can simultaneously enroll the present token and offline backup token(s) with the same relying party?
I wish for a completely local mechanism where a phone with a hardware security module could act like a token via completely local communication with the browser, both for enrollment and later login with any relying parties. For general users, I do like the idea of being able to backup/restore the token seeds to allow replacement of hardware without manually re-enrolling redundant keys with all relying parties.
But, I don't see why the cloud-assist should interpose between the user agent and the security device, nor why a cloud-assist should interpose between the user agent and the relying party. How is this cloud-assist different than the other vendors like Duo and Okta, interposed in enterprise client login attempts and organizing MFA options which can include authenticator apps on phones?
I feel like platform vendor lock-in has been gratuitously introduced into this plan. Couldn't a token backup/restore service be offered to users without interposing anything new service between the phone-as-token, the user agent communicating with the token, and the relying party service? Or, couldn't the token standards be amended with some sort of web-of-trust concept to allow a token to announce additional peer/backup token keys during enrollment. so that one enrollment task can simultaneously enroll the present token and offline backup token(s) with the same relying party?