-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WebAuthn and phishing #10
Comments
Could you elaborate on this more, please? If there's some reading material on this topic that you could provide, that would be appreciated.
Typically the web security boundary is the origin. If a
I agree that |
I'm no expert on WebAuthn but the idea was (for privacy reasons), to have one (or more) keys for each domain. That is, WebAuthn keys are protected from being shared among domains. Usually a Yes, the |
WebAuthn
deals with phishing by using domain-constrained tokens. Withmodal-window
the domain-constraint is effectively disabled. If you would like to use a direct mode (similar to client-side TLS certificate) for payments or authentication the design could benefit from also supplying the certificate path of the calling domain. As an example, this is a part of Google'sPaymentRequest
for Android. Certificate data would then typically be hashed into signed assertions.BTW, it is not clear to me how
WebAuthn
can be used from amodal-window
sinceWebAuthn
is activated from theWindow
object, unless theWindow
object (or a new property) as well as associated code is meant to security-wise belong to theService Worker
domain. I guess this is already the case?Anyway, the utility of
modal-window
IMO stands or falls with the integration ofWebAuthn
.The text was updated successfully, but these errors were encountered: