Administration of the Portals collection - the hostname allowlist that decides which origins may authenticate at all, and which WebAuthn relying party (rpId) each of them belongs to. See webauthn for what a relying party and a related origin are.

All four endpoints require access level ADMIN (security.token.minAdmin). Every write invalidates the in-process portal cache immediately, rather than waiting for its normal 60 second refresh.

{ portals: [ /* full Portal documents, sorted by hostname */ ] }

{
  hostname: 'admin.xint.dk',
  customer: null,
  name: 'Xint Danmark',
  rpId: 'xint.dk',
  relatedOrigin: false,
  enrollUrl: 'https://admin.xint.dk/#/passkey?t={token}&l={lang}',
  state: 'ACTIVE'
}

{ success: true, portal: { /* the stored Portal document, including _id, createdAt, updatedAt */ } }

Two checks run on every create and update, against the full resulting set of portals - not just the one being written:

1. Relying party reachability. A browser only accepts an rpId that is the hostname itself,

or a parent domain of it - or, failing that, the hostname must be published as a related

  origin. Concretely:
  * ''rpId'' with no ''.'' - a single label such as ''dk'' or ''com'' - is refused outright as a
    public suffix that no browser would ever accept. ''localhost'' is the sole exception, for
    development.
  * Otherwise, the write is refused unless ''hostname'' (without its port) equals ''rpId'', ends
    with ''.<rpId>'', or ''relatedOrigin'' is true.
- **Related-origin label budget.** If this write's ''relatedOrigin: true'' portals, combined with
  every other ''ACTIVE'' related-origin portal, would use more than 5 unique registrable-domain
  labels (excluding the anchor's own ''telecomx'' label), the write is refused - see
  [[api:auth:webauthn]] for why 5 is the limit.

Same body and validation as create, applied to an existing portal.

{ success: true, portal: { /* the updated Portal document */ } }

{ success: true }