#1127: WebAuthn Level 3: Related Origin Requests
Discussions
Log in to see TAG-private discussions.
Discussed
Aug 11, 2025 (See Github)
Matthew: Martin proposed a comment; LGTM; shall we ask him to post it?
Lola: Agree LGTM. Anyone have concerns?
Hadley: I don't disagree with any of it, but it's unclear to me what we want them to do.
Lola: When we resolve as unsatisfied, do we have to have an action item for them?
Hadley: No, but I would want to know what to do in order to make the TAG happy.
Lola: This seems simlar to RWS or other cross-origin stuff, where we say this goes against what we say for the web.
Hadley: I'd like to see something that gives them a next step.
Hadley requesting this on the private thread - we could come back to this in the plenary
Comment by @martinthomson Aug 14, 2025 (See Github)
The TAG has reviewed this and finds that the mechanism here is too similar to related website sets, for which we have provided more extensive feedback.
Overall, we're not satisfied that this is the right way to authorize cross-site communication or cross-site release of identification information. We do want to acknowledge that there are some redeeming aspects of this that make this more manageable than RWS. The use of prompting/choice UX that might look similar in nature to FedCM does a lot to mitigate the downsides of this approach, but we are not confident that this has been as carefully thought out as the FedCM interactions.
If those UX interactions prove to be as good as FedCM, then the method by which different sites authorize each other seems redundant in that context; a simpler approach is probably enough.
Discussed
Dec 1, 2025 (See Github)
Philippe: Had a discussion with the web payments working group this week. https://github.com/w3ctag/design-reviews/issues/1127
Apparently this caused a lot of confusion.
This issue was created in the TAG repo, not in the specification review. Martin comment and closed the issue. We received a request for the document two weeks ago. it looks like the WG didn't address the issue, so we declined to allow them to move forwrd, asking for clarification. They said "the issue was closed". We suggested that they should consider addressing the spec. We understand that some people met with the group on Sep 3. There were no conclusions or minutes. I need to understand if this is OK with the TAG or if you have an issue with it. If there is an issue, then I would like the TAG to open an issue against the specification so that the group can address it properly.
Jeffrey: I feel like the TAG still has an issue with the spec. It's fine to ask us to open that issue. I don't think that we can decide that a spec doesn't advance, but the group should document how they handled the objection. I think
Martin: Can recover state and open an issue.
PLH: You are not the only one to have feedback, so this is not on the critical path. but sooner is better. We need clarity.
Matthew: From TAG perspective, it's quite clear that the way the issue was closed was not satisfied. it was closed because our work was done. Others can ask us to reopen if they have new information. Maybe there is a misunderstanding about how the TAG works. It's totally normal for a horizontal review group to raise issues in the originating repository, but I don't think that we have consensus that the TAG is a horizontal review group. So we tend to just provide feedback on our threads and don't have issues with other groups. The non-standard part here is that this is a separate issue; so maybe they missed it.
PLH: They weren't aware or considered the issue resolved.
Matthew: the high-level issue was resolved satisfied, so maybe there was a problem with the way the review was requested. This was not one review for one feature. 1127 was linked from the main thread and it was clear.
PLH: If you open an issue in their repo, that will close the loop.
Yves: It's quite likely that the WG did look only at the label and not at the content of the feedback when closing the issue. That's what I heard. Perhaps this was not as explicit about the connection to first party sets.
PLH: This issue is not gone. I want that to be on the record. Both the TAG and privacy people think that this should not be in the spec. Apparently three browsers already implement the feature. This is not an easy issue at all.
Lola: Happy to be corrected, but we as TAG do not say whether or not browsers implement something. We say whether or not it should be implemented as proposed. It doesn't matter that browsers implement, because that's not what we are commenting on. I do think that Martin's comment is quite thorough in what we disagree with on both issues and the part is what is similar to related website sets, regardless of who implements it. They are free to pursue this, they don't need to listen to the TAG. But I don't know how we could be clearer about the issue we have based on the comment that already exists. Asking Martin to open an issue on their thing feels redundant. Unless the request is to re-review what they submitted.
Jeffrey: The idea is just to ensure that the issue is tracked somewhere.
Lola: PLH, did you say that their fix is "the browsers have implemented"
PLH: I don't want to speak for them, but they are not likely to do anything. Difficult situation. Can we pretend that reality doesn't exist, or is there something else we can do?
Jeffrey: There is always the option to file a formal objection. At which point we'd get another go at this on a council. ...Lola said that we don't care what is in browsers. I think that we do care, but we are not dictators, only advisors.
PLH: Question about how much we want specs to reflect reality.
Jeffrey: We have next steps. We will see what the WG wants.
OpenedJul 31, 2025
This tracks this as something separate from the main #1085 review request.
<!-- Content below this is maintained by @w3c-tag-bot -->Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1127