Platform authentication registration promotion when the user has authenticated with the external authenticator

[Kieun]

If the authentication response coming from the external authenticator or phone (with hybrid transport) and the client device supports platform authentication, it is recommended for RPs to provide promotion to that user to register the platform authenticator. The user might have a chance to select their authenticator during authentication process (platform authenticator, security key, hybrid and etc). Even if the credential is generated on the platform authenticator of the user device, the user still can authenticate with other authenticators (such as security key and phone - hybrid). In that case, as a RP, the RP has no way to check whether the credential has been created on the platform authenticator or not.

What's the recommendation in this case? Just promote the user whenever the user has authenticated with the roaming authenticator? Or, leverage cookie to indicate that the platform credential is registered before?

[agl]

Just promote the user whenever the user has authenticated with the roaming authenticator?

This, within reason, I believe. (Personal opinion.)

Conditional UI support should make using local credentials easy for a user. Even in the case of a traditional assertion UI, sites should expect that platforms will prominently offer local credentials(*). If the user signed in using another authenticator, it's probably because they don't have a local credential.

(*) Not necessarily true yet.

[Kieun]

@agl Probably, Conditional UI helps for the user to leverage local credential if exist. But, how can we distinguish that the credential is coming from the platform authenticator or from the roaming authenticator (especially phone as a security key)? For get (assertion) response, I think there is no such information that RP can refer. Which specific information RP should look into?

[agl]

But, how can we distinguish that the credential is coming from the platform authenticator or from the roaming authenticator

The authenticatorAttachment value in the resulting object will tell you if the device used to generate the assertion was platform or cross-platform.

[emlun]

Note also that authenticatorAttachment is available in both the create() and get() responses.

[Firstyear]

But, how can we distinguish that the credential is coming from the platform authenticator or from the roaming authenticator

The authenticatorAttachment value in the resulting object will tell you if the device used to generate the assertion was platform or cross-platform.

This value is un-signed and can't be trusted to be valid or correct. Just the same as the resident key status, it can be freely altered by client side tooling and js.

@Kieun As an RP the only thing you can trust is signed, attested properties. To determine the attachment you need to look at the CA used in attestation, and then subsequently the device AAGuid to understand what the attachment was during a ceremony.

[Kieun]

@Firstyear Yup. The transport might be the security properties for the certain RPs. But, I'm more concerning about the UX flow. In many situations, the metadata is unavailable. So' I don't want to rely on the meatadata and aaguid to decide the UX flow.

[Firstyear]

All good, so long as it's just for UX flow, that's fine to use the authenticatorAttachement there.

[Kieun]

One thing to note is that the authenticatorAttachment in the create() and get() response is nullable. Sometimes the RP might not get any value from the response. I don't know why.

[agl]

One thing to note is that the authenticatorAttachment in the create() and get() response is nullable. Sometimes the RP might not get any value from the response. I don't know why.

Older browsers exist that will not provide that value. In those cases you probably don't want to prompt the user.

[Kieun]

Older browsers exist that will not provide that value. In those cases you probably don't want to prompt the user.

@agl If it is the case, then the value should not be null in the new version of the spec? For old browser cases, the attribute itself does not exist in the PulbicKeyCredential interface.

[ghost]

Show off-topic comment

hello, has the chaos already announced my appearance? What do you actually use from me that makes my authentication noticeable to you? I hope I haven't caused any major damage? I've been keeping this phone alive for 3 years, it's a scam victim. 3 years ago it was a cryptowallet and since then I haven't had a chance to sign up. The website is gone and the app tries to log in to the network but the server no longer exists. A few days ago I discovered a Fido2 token that allows me various authentications and I wanted to know if it can give me information that I don't have yet. But I was shown 140 problems and I'm trying to solve them. Yesterday it was only 32 and today it's 80 again. The problems must be affecting security, so I haven't authenticated yet. I have all the passwords, the SIM, the Fido2 token, only the mobile phone was exchanged, but I was able to save the faceID data. Unfortunately, I only read the note today that a new authentication has various side effects. When I wanted to see the extent of the damage, I saw your conversation and logged into GitHub. How do we get the cow off the ice? I've been searching and learning for 3 years because something keeps me from throwing away my cell phone. The token is the first opportunity to communicate with the platform or my wallet. If neither of them exist anymore, I can at least stop the search and accept the scam. Why do scammers give me the safest wallet on the planet? Isn't that counterproductive? And I know what I'm talking about. It's so secure that I haven't even gotten my money to this day, even though I supposedly have all the keys. But Fido has already solved the problem. Nevertheless, I would like to know if there is still something from the value chain, preferably without leaving you with a pile of rubble. If I understand correctly, you optimize processes and networks. I can do something with that because I'm a measurement technician and I work in gauge construction. A job for perfectionists! I would suggest that you first tell me if and how you use something of mine. I'm thinking about my favorite coin, Algorand. If I had to guess, I'd say you're running an orphaned blockchainplace in the frontend or backend. The mobile phone has never been anything other than an e-commerce tool. I don't use it as a telephone. I'm curious about your answer and I can understand that dead accounts are used. The account is dead but not masterless! I'm Michael from Germany and could use some help so I don't destroy your work, and because I actually have 2 blockchain places, I still have another phone with wallet and Fido2 token. 🤗

[emlun]

@Querulant I don't think I quite understand what you're trying to say, but if you're having trouble with a cryptocurrency wallet or exchange I suggest you turn to the support channel for that wallet or exchange. This repository is for the WebAuthn spec, which is not concerned with cryptocurrencies or blockchains. Either way this seems unrelated to this issue, so I will edit your comment to keep things tidy. If you still believe your questions are related to the WebAuthn spec or FIDO technologies, please turn to the public-webauthn@w3c.org or fido-dev@fidoalliance.org mail list instead.

[ghost]

Show off-topic comment

Thank you for your answer, and obviously the shown countless problems that are displayed to me is to much . this ist the wrong group. I saw the following information: Web Authentification: An API for accessing Public Key Credentials Level 3 Editor's Draft, (29 June 2022) new This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. Please use Github issues. but today the editors draft is new it is not the draft i read. I had read that I should contact github issues before authentificating because my authentification would affect ongoing operations?! Before my authentification, preparations or changes would have to be made to ensure proper operation. that means for me that someone is authenticated but not me. I have no idea where this is going to. I only know that the Fido2 token registered me with my wallet. I got the token when registering the wallet. I don't know what will happen if I authenticate myself again after 3 years. It is also strange that platform authentication is no longer possible today. Yesterday was alI possibel userauth webauth plattformauth . I would say level 3 is a joke. I look at level 2 if the platform authentication is possible. (Do you think I wait 3 years If I can call the Wallet Support). 🤨No Support no Projektteam No technical Team No App and No Exchange only Fido2 Token ( He knows every Detail and don't forget something. he is a better support )!!! I apologize for the disturbance and wish everyone a pleasant Weekend. Best regards michael

[agl]

If it is the case, then the value should not be null in the new version of the spec? For old browser cases, the attribute itself does not exist in the PulbicKeyCredential interface.

Discussed during the meeting of 2022-09-12: this field is nullable because the browser may be new enough to know about the field, but unable to learn this information because the platform is too old to provide it. So we feel that the current, nullable, field is correct.