- From: Corentin Mors via GitHub <sysbot+gh@w3.org>
- Date: Mon, 05 Apr 2021 21:14:46 +0000
- To: public-webauthn@w3.org
@dwaite this makes sense and this how U2F is currently working, you set your appID / RPID to be your `domain.com` then a roaming authenticator is usable accross platforms. For anyone jumping in the conversation, the part of the spec we are talking about is: https://w3c.github.io/webauthn/#rp-id > By default, the RP ID for a WebAuthn operation is set to the caller’s origin's effective domain. This default MAY be overridden by the caller, as long as the caller-specified RP ID value is a registrable domain suffix of or is equal to the caller’s origin's effective domain. > Other specifications mimicking the WebAuthn API to enable WebAuthn public key credentials on non-Web platforms (e.g. native mobile applications), MAY define different rules for binding a caller to a Relying Party Identifier. Though, the RP ID syntaxes MUST conform to either valid domain strings or URIs. So the implementation of browser extensions should be adapted to be able to use the owner's domain (how the verification could be done is an unknown). But then this differs from the initial topic of this issue which was about allowing cross-domain use between `a.c` and `b.c`. Shall we create a different thread? -- GitHub Notification of comment by Mikescops Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1372#issuecomment-813654297 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 5 April 2021 21:14:48 UTC