These are known gaps and unresolved design decisions in the current protocol architecture. They are published openly to invite collaboration and to be honest about what remains unsolved.
Handle registry and conflict resolution Open
IdunHandleClaim needs a concrete mechanism for resolving handle conflicts. Current proposal: first-claim-first-served tied to a verified DID. But what about name squatting? Trademark disputes? The DNS model (registrars + dispute resolution) may be the pragmatic answer, but adds centralisation.
Approaches: First-claim with DID binding, namespaced handles (@alfred@inlagg.se), or delegated to platforms with Idun as the portability layer.
Content portability on ActivityPub Partially solved
AT Protocol solves this with signed personal data repos — content is portable by design. ActivityPub does not. Posts delivered via AP can be discarded by receiving servers. Idun should define a content backup standard or recommend AP platforms implement content mirroring.
Approaches: IdunContentAttestation credential for authorship proofs, recommended content export format, or AP platforms adopting AT Proto-style signed repos.
Reputation credential revocation Partially solved
Credentials are self-contained and user-held. What stops a banned user from hiding a bad reputation credential? Current mitigation: short TTLs (90 days) so platforms only trust fresh credentials. But this means reputation doesn't survive platform shutdowns well.
Approaches: Short TTL + mandatory refresh, platform-published revocation lists, or a model where platforms query rather than trust presented credentials.
Governance model Open
Who decides what credential types exist? Who approves spec changes? "Open source" is a licensing model, not a governance model. Idun needs a formal process for protocol evolution.
Approaches: W3C-style working groups, OpenID Foundation model, or Rust/IETF-style RFC process with community consensus.
DID method selection Under consideration
did:web is simple (your DID is a URL you control) but depends on DNS/hosting. did:plc (AT Proto) is portable but currently centralised at Bluesky. did:key is fully self-sovereign but harder to rotate. Idun may need to support multiple DID methods.
Approaches: Support did:web as default with did:plc bridge for AT Proto interop. Allow users to bring any DID method that meets minimum requirements.
Swedish BankID ID-switching constraints Workaround needed
BankID prohibits using BankID authentication to issue alternative credentials. This means a "verify once, use forever" wallet model may violate BankID terms. EUDI Wallet (launching late 2026) is expected to resolve this at the EU level through standardised credential exchange.
Approaches: Use BankID as pass-through auth until EUDI Wallets launch. Use MitID (Denmark) or Freja+ (Sweden) where wallet models are permitted. Design for EUDI Wallet as the primary path from 2027.