-
Notifications
You must be signed in to change notification settings - Fork 66
Allow accepting any topOrigin value #493
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
base: master
Are you sure you want to change the base?
Conversation
santiagorodriguez96
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good overall! Just a couple of little things to discuss 🙂
| context "when top_origin is not set" do | ||
| let(:client_top_origin) { nil } | ||
|
|
||
| it_behaves_like "an invalid attestation response that raises", WebAuthn::TopOriginVerificationError | ||
| end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not entirely sure about raising an error if allowed_top_origins is allow_all and topOrigin is not set. Why do you think we should do it that way?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understood that in L3 when crossOrigin is true there MUST be something set in topOrigin, but I'm not sure TBH
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking about a relying party with verify_cross_origin enabled and allowed_top_origins as :all more as a L2 relying party – as mentioned on this comment:
It is probably correct that an "L2" RP, expecting crossOrigin: true, topOrigin: undefined, should accept an L3 client data with "crossOrigin":true,"topOrigin":"", since "topOrigin" is an unknown attribute to that RP and so it falls under the "allow any trailing attributes" rule in the final step.
However, by doing this then it would be basically the same as ignoring the cross origin verification, with the difference that it will fail is crossOrigin is false but topOrigin is present, which is not really the behavior of a L2 RP 🤷
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should consider if it's worth adding this?
The value that it provides is that a RP that sets :all as the allowed origin is that responses with crossOrigin being false and topOrigin being nil and with crossOrigin being false and topOrigin being something will both be considered invalid – but I'm not sure if users of the gem that wish to allow any top origin will care for those scenarios...
We could leave it as it's currently is and make users of the gem that wish to allow any top origin to simply ignore the cross origin verification in the configuration.
What do you think? Am I'm missing something?
Summary
Allow accepting any topOrigin value.
References