- From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
- Date: Tue, 05 Dec 2017 16:18:34 +0000
- To: public-webauthn@w3.org
@agl is correct, the AppID is not needed for new registrations. To elaborate: the _application parameter_ sent to U2F authenticators is an [opaque binary array][u2f-authenticate] containing the SHA-256 hash of the AppID; the validation of the AppID is done by the client platform. U2F authenticators are therefore compatible with WebAuthn RP IDs for new registrations since they only see the hash. The difference in format between RP IDs and AppIDs can be handled fully by the client. A U2F credential registered via WebAuthn wouldn't be usable with an RP that only knows about U2F, but since credentials aren't shared between RPs this is not a problem. Likewise the credential wouldn't be usable with a client that knows only about U2F, but since that client wouldn't itself be compatible with the RP this is also not a problem. Therefore the AppID is not necessary for new registrations. --- What _could_ cause trouble, though, is point (4): >If valid, the value of _rpId_ for all client processing should be replaced by the value of _appid_. At present the _rpId_ seems to not be used in any other client extension processing, but this could possibly cause confusion with future extensions. Then again the RP would be aware since it has to explicitly opt into this behaviour, so I guess it would only matter if other extensions for some reason expect _rpId_ to be of the RP ID format. [u2f-authenticate]: https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-raw-message-formats.html#authentication-request-message---u2f_authenticate -- GitHub Notification of comment by emlun Please view or discuss this issue at https://github.com/w3c/webauthn/issues/491#issuecomment-349355692 using your GitHub account
Received on Tuesday, 5 December 2017 16:18:41 UTC