search

mozilla / standards-positions

https://mozilla.github.io/standards-positions/
Mozilla Public License 2.0
653 stars 73 forks source link

WebAuthn related origins #1052

Open agl opened 4 months ago

agl commented 4 months ago

Request for Mozilla Position on an Emerging Web Specification

evilpie commented 3 months ago

/cc @jschanck

dveditz commented 1 month ago

This seems like it would have similar objections to the "First Party Sets" proposal. Maybe some or all of those have been addressed since Apple was opposed to those and apparently shipped this. I do note the proposal limits the number of domain labels, which addresses one set of concerns.

I didn't see anything in the spec requiring UAs to request the .well-known file with no credentials and no referrer, to prevent sneaky domains returning customized lists to get around the size limits.

I'm not sure how I feel about about supporting redirects for this yet. Some features using a .well-known file support redirects and others forbid them. But if it does support redirects it should explicitly require all redirects to only use the https: scheme

The spec says relying parties "MUST choose a common RP ID to use across all ceremonies from related origins". If that's an anti-abuse requirement you can't leave it up to a potentially-sleazy RP to enforce. It sounds nice (it seems like an important safeguard), but without a defined enforcement mechanism it's just fluff. It's not something an individual UA could try to police (without an agreed spec mechanism) because if they're the only one doing it sites won't care and it will just be broken for that UAs users.

[these are just my initial-impression thoughts in a conversation (I hope) with others—not a conclusion and definitely not "Mozilla's position"]

timcappalli commented 1 month ago

The spec says relying parties "MUST choose a common RP ID to use across all ceremonies from related origins". If that's an anti-abuse requirement you can't leave it up to a potentially-sleazy RP to enforce.

It is not for anti-abuse. It is a core requirement to make the solution usable. If you don't use a common RP ID, you can't use passkeys across related origins without asking for a username. This is explained here: https://passkeys.dev/docs/advanced/related-origins/.

But if it does support redirects it should explicitly require all redirects to only use the https: scheme

Can definitely add that clarity.

to prevent sneaky domains returning customized lists to get around the size limits.

Not sure I understand the concern here. The well-known is requested by the WebAuthn client and is only used by the client to process credential selection. Clients also have a max number of labels supported which cannot be influenced by an external party (both in market implementations are capped at 5).

emlun commented 3 weeks ago

to prevent sneaky domains returning customized lists to get around the size limits.

Not sure I understand the concern here. The well-known is requested by the WebAuthn client and is only used by the client to process credential selection. Clients also have a max number of labels supported which cannot be influenced by an external party (both in market implementations are capped at 5).

I think the concern is something like this: if the client sends a Referer header in the .well-known request, a sneaky RP could use this to return different .well-known contents when requested from different pages. This could enable it to use the same RP with up to 5 additional labels for each page, bypassing the intended limit of 5 labels per RP ID.