Skip to content

Conversation

@nicolastemciuc
Copy link
Member

Summary

Allow accepting any topOrigin value.

A web application that wishes to be embedded in a cross-origin iframe on a large number of domains might allow any value of topOrigin.

References

Copy link
Contributor

@santiagorodriguez96 santiagorodriguez96 left a 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 🙂

Comment on lines +977 to +981
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
Copy link
Contributor

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?

Copy link
Member Author

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

Copy link
Contributor

@santiagorodriguez96 santiagorodriguez96 Oct 31, 2025

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 🤷

Copy link
Contributor

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants