Torgo: we haven't made progress on this. I'll talk to Matthew about it.

Hadley: does it need agenda+? is it a high priority?

Torgo: I'll discuss that with Matthew too.

touch on this at the plenary and try to re-assign

Martin: the related origin idea smells a lot like related web site sets… Example.com vs. example.co.in. We may want to take a position on that. It may be that the credential requires some kind of interaction from someone..

“we propose a well-known URL where an origin can list other origins that are authorized to use it as an RP ID” — https://passkeys.dev/docs/advanced/related-origins/

Dan: Going to check with Simone about where this is at.

Martin: Also, look at https://github.com/w3c/webauthn/wiki/Explainer:-Cross%E2%80%90Origin-Credential-Creation

touch on this at the plenary and try to re-assign

Martin: the related origin idea smells a lot like related web site sets… Example.com vs. example.co.in. We may want to take a position on that. It may be that the credential requires some kind of interaction from someone..

“we propose a well-known URL where an origin can list other origins that are authorized to use it as an RP ID” — https://passkeys.dev/docs/advanced/related-origins/

Dan: Going to check with Simone about where this is at.

Martin: Also, look at https://github.com/w3c/webauthn/wiki/Explainer:-Cross%E2%80%90Origin-Credential-Creation

Matthew: I have feedback from a new starter, Ehsan, our privacy expert. Matthew to paste into the private brainstorming

DanA: I discussed with Simone from W3C yesterday. Talked him trhough our feedback and passed on Martin's comments in PB issue, so that he can bring that feedback to the group, especially the related origin requests. I told him it starts to sound a lot like first party sets or related website sets, and we've had negative feedback on that because of the centralisation aspects. "Cross origin yada yada".

Simone was keen to say that authentication in general is being designed to mitigate against phishing attacks. There are apparently additional features and evolution in each one of these specs to help with this goal. I told him we found this difficult to deal with, because there are a lot of new specs here, a lot of information, we don't have the overarching story ("Here's why we're doing the level 3. Level 2 had these problems, and so we addressed them in this way."), instead we just have a laundry list of changes.

Simone said he would feed that back to the group and have them get us additional context.

I also understood that related origin requests are new. They may be the one thing we want to discuss separately, whereas the other things in this list are evolution from webauthn level 2, which we've already positively reviewed.

Matthew: Reminded me: the related origin requests... caused concern... we've come across a number of design review requests where some parties want to express a relationship between domains or sites, and this keeps coming up. Maybe we should have a recommend way of doing this... We could make a list where this problem has cropped up. Some of the ways that have been proposed have been bi-directional handshakes... but the one from Fido is single directional... no handshake. That seems weird. One of the things we've been doing is making a list of those. We should have a themed discussion.. distinct use cases...

Lola: +1

Jeffrey: the fact that Dan's trying to get a unified description of what's in level 3 ... is exactly what my revision to the intake forms is trying to cover...This is good experience to put into https://github.com/w3ctag/design-reviews/pull/1102/files#diff-2a399f4304b1d6f153f81b578004a7eb8b9c108f52b56c22625a2d57f6df8497 (WG revision reviews) Not sure how to cover it. I want to nominate Lola to organize what do we do about related web sites...

Dan, Ehsan (nominated as an Associate), Lola to work on it

we agree to put a new issue in our web platform gaps repo to write that

Hadley: what do we want to do with this issue then?

Dan: let's keep it where it is, and I'll keep chatting with Simone about it. I'll put in the issue that I've asked for more context.

DanA: Will comment in review issue. We need an overarching explainer/vision for Level 3; there are lots of explainers and specs to review in this one request.

Jeffrey: As Yves mentions, maybe this is something that Passkeys.dev explains, what bit of the story that would fill in that we are missing here.

Hadley: Maybe in the charter?

Jeffrey: Charters being time-based, I'm not sure. Seems more a grab bag of features https://www.w3.org/2022/04/webauthn-wg-charter.html

Hadley: Would be good if the Charter has this info.

Dan:

We appreciate this is a lot of work and that you've provided a great deal of info for this review request.

As discussed with @simoneonofri this week, the TAG would like a bit more context on the overall high-level story here about the revision of WebAuth to level 3. Is there an over-arching vision for the new level (e.g. addressing specific threats that have emerged, which level 2 did not address), or is this an incremental update? Is there a summary already written somewhere that you could link to? Another option might be for someone to come to a future TAG call to discuss.

Also related origin requests seems to be more of a new feature... Is that correct?

Hadley: Could ask if there's a summary already written somehwere? Or would they like to come to a TAG meeting?

DanA: Mentioned that suggestion; group is considering.

Hadley: We should also ACK that they put a lot of work into what they've already done. Sounds like a lot of explainers.

Matthew: Last week I put in Ehsan's tuppence. Some bits are what's missing from explainers. We talked about it in TAG calls last week. Dan asked for the overall motivation. Asking for a primer about the series of specs. Looked at the feedback in Private Brainstorming, and haven't gotten to addressing our concerns.

Jeffrey: So we need to draft an opinion comment?

Matthew: We should invite them to a TAG call. Dan's court to invite them to a call.

Related Origin Requests

Martin: First in the list is Related Origin Requests. This smells really bad: cross-origin communication, violating the privacy principles we set up. Fact that it's user-mediated somewhat ameliorates that concern, but doesn't completely cover it. Not clear that the interaction with a token is deliberately allowing the release of information across sites like you might with Storage Access or FedCM, which are the cross-origin [ed: site?] mechanisms we have. We see the use cases, but that doesn't create a justification. Talk about this?

Tim: Both the RP ID and the origin can be presented to the origin. Restricted to 5 labels, which was consensus. Some wanted it to be much higher, but we expect this to be mostly country codes. Largest deployments wouldn't be able to use this without this feature.

Martin: If that's the case, why have the 5-label restriction?

Tim: Just do cctld?

MArtin: Looks like you're going down the design path of Related Website Sets. That least to lots of problems. But seems like the same scenario. But you're talking about something like FedCM. Like google.com.au and use the passkey that I registered at .co.jp. In that case, it could have the same UX as FedCM.

Tim: Kinda does? Every passkey flow has a dialog.

Martin: At that point, we're not stopping Google's IDP from being used across 1M sites. You've met the same bar, so why have the restrictions on the size of the set?

Tim: Difference is that these are only same-party credentials. Federation is the opposite.

Martin: But that's an artificial construct, since google.com is different party from google.co.jp.

Matthew: There's an explicit opt-in so organizations have to establish relationships with eachother.

Tim: Far more restrictive than first-party sets.

MArtin: Good safeguards, since you want consent from entity that created passkey and RP. Saying "I have this credential, and I'm allowing some other entities to access it." That's the mutual acknowledgement. You've got this restriction on the number of origins that doesn't make sense.

Tim: We put that restriction in so a social media provider can't add all your origins to their RP. Majority of RPs needed at most 5, and jsut for vanity use cases. E.g. amazonprime.com vs amazon.com.

Martin: If we look at how FedCM operates, and it's the same or scarier. Why do you need that restriction. You say "I'm going to amazonprime.com and logging in with amazon.com credential". Looks like FedCM flow. The Amazon restriction to only

Matthew: Dancing around the idea that federation should be the solution instead?

Martin: Trying to bring this to the user-experience level. I'd have started with "federation is my preferred approach", but that's not how the system operates. The UX is I go to a website and want to log in. Asks me for a passkey. Something happens. Some passkey I created on another website is activated. Tim pointed out that the question presented is "you're on this site; can this site log in with this other passkey". Depends on the UX whether I think it'll be acceptable.

Tim: Are you advocating for dropping the limit.

Martin: If the defense is the UX. Problem is that the UX wasn't present. No discussion of the UX in the explainer or spec.

Tim: No UI guidance. We don't discuss UI in the spec. Origin in the url bar is what needs to be validated. This changes the selection.

Martin: Don't want to overspecify the UX; that's a browser competition thing. At the same time, if there's nothing in the spec that constrains the browsers, that's a problem. If the expectation is that the browser will present information to the user in a particular way so the user needs to understand the interaction, we need to write that down.

Tim: Very rare that the browser will show UI. WebAuthn client is different from the user agent. WebAuthn client does this lookup.

Jeffrey: Martin is advocating for one of two things: either this is restricted to same-site (no information crosses the boundaries) OR it should have something about the UX in the spec, minimally that it should ask permission to link identities across the sites. In the latter case, there is no need for the five site restriction. The handshake is still useful to have sites opt-in to communication. There has been a lot of disagreement about how much UI to put in specs. Alex Russell argues for none, Martin and I argue for some. For instance, you need to tell the user both sites. It's true that browsers can't do that themselves, OS needs to. The spec could still state requirements.

Tim: That does largely exist. Even before this, it's expected to show "you want to show this RP on this origin". That does exist. Hasn't been a huge shift here. With cross-origin create, we added the ability to pass both top-level and real origin. Don't know how to require UX for this when it's required for the other pieces.

Martin: I think that's not enough. Had a debate around FedCM. It has a chooser arrangement, not a "click here to lose privacy". Means that when you go to a website, the choice of IDP -- in this case the choce of passkey provider -- is something the user chooses from a list. Not just presented with a yes/no option. If I can't produce that UI, that's a problem. And I think you can't because it's passed to the OS.

Tim: I struggle with the comparison to FedCM: they're fundamentally different.

Martin: I don't want to be in a situation where someone's presented with an option where one is the wrong one to press, and there's an irrevocable loss if they pick the wrong one. I fyou press yes, your identity is permanently linked. E.g. Big Company buys popular service, they immeidately want to link accounts. Arrive on service you've been using for a while, and it shows a message. Gibberish. "Sure, why not?" And that's irrevocable. Scenario that'd happen with these things. Understand that most experiences aren't that. Usually easily understood.

Tim: In order for that to happen, both parties would have had to exchange their user databases on the backend.

Martin: Sure; they could already do that, but user doesn't need to be complicti.

Matthew: W3C Position or TAG position?

Martin: No, but we have principles that state people need to be in control.

Jeffrey: If a site says that they want to use a passkey, the OS might find passkeys from other places. I might disagree with Martin about FedCM, which allows that. Martin's goal is that it is possible to build a chooser rather than an accept/deny interaction. With a list, users are a little bit more in control. Maybe they can see that passkeys exist and make a choice. Passkeys could offer passwords as well, because it uses credential manager. I'm less worried than Martin: it could be built to provide a list.

Tim: In the case you have a passkey where the RP and passkey RPID match. I have an amazon.com passkey, and I visit amazon.co.jp with an RP ID of amazon.com. It'll look for amazon.co.jp, and offer that up.

Jeffrey: That is what Martin is worried about. Can the browser make that possible?

Tim: The user will literally not have a credential. Large deployments say that they can't roll out passkeys without this. Won't be able to access sites when traveling.

Matthew: Time check.

Cross-origin iframe registration

Martin: I'm on a vendor page, and my bank has a frame and wants to create a passkey?

Tim: Neither of us was involved in writing that. I think it is about SPC. I think it's about the get, not the initial enrollment. Let's ask Stephen. Not universal agreement on this one.

Matthew: PR is at https://github.com/w3c/webauthn/pull/1801.

Client Capabilities

Martin: Relatively straightforward. Fingerprinting, but mitigations are poor. Permissions policy isn't effective.

Tim: Those mitigations were from Mozilla; we didn't have any to start with.

Martin: Giving UAs discretion about what they reveal is the strongest, but worst for web compatibility.

Tim: That also came from mozilla. John wanted cross-device. Requires device to have bluetooth. If you're a browser that supports Web Bluetooth, so you're getting BT permission for other things. That should correspond. Mozilla wanted to not return it or return false. In no case where it's false in one browser and true in another, is that worse than not having Client Capabilities in the first place. If site can't tell what's there, they can only do basic flows.

MArtin: Strongest mitigation is the reduction of information along those lines. But doesn't seem liek there's been rigor put into that. There's been work on WebGPU to bucket things instead of the multidimensional thing.

Matthew: Are there any other feature-detection APIs to look to for prior art? We'd look at those for guidance. (WebGPU)

Martin: Most that exist aren't great examples. WebGL has queryable extension points, but it's too rich a fingerprinting surface. Better to say "if you have this large group of features, suddenly they all appear". Not sure any of this is justifiable. That discussion needs to happen. How much fingerprinting, and what do we get in return?

Matthew: If it can be seen as a way to check for various features. Through that framing, how's it greater than individual feature detection that you could do without it?

Martin: typically you can feature-detect on a piecemeal bases, but it only depends on the version of the browser. E.g. Chrome 120 has one set of capabilities, and 130 has different, and every 130 has the same capabilities. HErre this might be determined by what hardware is present. Capabilities of the hardware, whether a phone is nearby.

Matthew: GetClientCapabilities doesn't expose even the perrmission that have been granted to browsers. It's whether the client's aware of it as a feature, not whether it'll be successful. RP uses GCC. "Hybrid" permission. You can invoke it in a way that Hybrid would be invoked, and GCC might return true, but the call would fail.

Tim: Only hardware element that would be exposed is if the device doesn't have BT.

Martin: That could solve that reasonably. If it's just about the browse rimplementation, then there's nothign special here, and fingerprinting isn't increased.

Tim: Use case of "is cross device available" comes from Samsung where the hardware isn't available.

Martin: Seems to me that the efforts you've taken make it sound like there's more fingerprinting risk than there really is. If it's nothing more than that, you should say that instead of putting in mitigations.

Tim: Chrome 130 on 2 devices, one with a platform authenticator, and one without, will return different values.

Martin: List those variances, and concentrate on those. For each one, evaluate whether it's worth it.

Jeffrey: For some of those, the browser would say "I have that hardware" because it understands the API call, and then it can fail at runtime.