mirror of
https://github.com/pocket-id/pocket-id.git
synced 2026-03-01 11:21:53 +03:00
🚀 Feature: Related origins for webauthn via .well-known file #532
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @webash on GitHub (Nov 3, 2025).
Feature description
Allow Pocket ID passkeys to be referred to from multiple domains using the related origins declaration in the webauthn .well-known file:
https://w3c.github.io/webauthn/#sctn-related-origins
Pitch
To allow Pocket ID to be referred to on multiple domains, making migrations easier in the future, and potentially allowing for special network-specific routing on different URLs.
@stonith404 commented on GitHub (Nov 3, 2025):
I’m not sure adding related origins will help with migrating to a new domain. Related origins only apply during passkey creation, so if users have already created passkeys, adding a related origin afterward won’t have any effect.
Also, regarding your second point using different URLs, that’s not possible either. Pocket ID only supports a single URL, since OIDC clients can specify only one URL for the identity provider.
@webash commented on GitHub (Nov 12, 2025):
Understood.
What I was hoping for is a situation where I might have the app on
iteration0.example.comandpocketid.example.comso that when there might be a breaking change, or a whole new instance that I want to provision to replace the old one, I could test it oniteration1.example.comand then swing it topocketid.example.comwhen it comes time; allowing both the old keys and any new ones that have been provisioned while it was oniteration1.example.comto still work.I think I'm coming at this from my systems/enterprise architecture background where there always wants to be flexibility on these things because ultimately businesses change their minds, or issues that are unknown to you right now come up later forcing a change.
OIDC is less of a concern to me because that is not immutable - URLs can be updated in the relying party config.
@webash commented on GitHub (Nov 12, 2025):
(and as an aside, @stonith404 ; absolutely wonderful work you (and others!) have done to create this software, I look forward to giving time and/or money towards the project when I have the means)