2 ms·

This is one of the main topics of the agreement discussed in the article - an agreement on how to use a phone as a cross-platform compatible authenticator and a

by dwaite 4y ago

This is one of the main topics of the agreement discussed in the article - an agreement on how to use a phone as a cross-platform compatible authenticator and a commitment to do so. The mechanism is already available on chrome and android if you select the option to add an android phone - iPhones and iPads have a developer preview feature flag you can enable to work with this as well, and to have a Mac display a similar option when using the platform level support (aka Safari or certain native apps).

saltcured 4y ago
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?

by dwaite 4y ago

saltcured 4y ago

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?