Skip to content
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

RelyingParty#id should default to the domain of #origin #427

Open
asavageiv opened this issue Apr 26, 2024 · 3 comments
Open

RelyingParty#id should default to the domain of #origin #427

asavageiv opened this issue Apr 26, 2024 · 3 comments

Comments

@asavageiv
Copy link

Per the spec the RP ID "must be equal to the origin's effective domain, or a registrable domain suffix of the origin's effective domain." and "By default, the RP ID for a WebAuthn operation is set to the caller’s origin's effective domain."

I was surprised that setting the origin did not automatically set the ID if it was unset. This led to failures when my Android client didn't receive an ID.

Can we set the ID by default per the spec?

@santiagorodriguez96
Copy link
Contributor

santiagorodriguez96 commented May 3, 2024

Hi @asavageiv!

Thank you the report!

Currently, if the user has not set an rp_id, we we'll derive it from the specified origin when verifying the authenticator response.

I find it surprising that this was an issue for you when using an Android Client – I'm curious, what issue were you experiencing exactly?

We might have to re-think about the approach that we are using here!

Then again, thanks!

@asavageiv
Copy link
Author

Android expects the rpId to exist in the challenge.

@santiagorodriguez96
Copy link
Contributor

Sorry, I did not mention that the rp_id will in fact be sent in the PublicKeyCredential::CreationOptions (see this) and PublicKeyCredential::RequestOptions (see this) if it was set for the relying party, so you should be good if you configure your relying party with your app's rp_id.

Now, about the rp_id defaulting to the domain of origin: by looking at the spec, sending the RPID in the creation and request options is optional – if it's not sent it will already be populated with the domain of your app's origin by the client. I think the behavior of webauthn-ruby it's pretty close to what's described in the spec - it doesn't send the rp_id unless the user of the gem instantiates its relying party with a value for it – so I don't think we should do anything in this case.

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

No branches or pull requests

2 participants