The function in an originating network that decides the attestation level for a call, builds the PASSporT, signs it, and adds the Identity header.
The authentication service sits on the originating side of a call, usually reached from the softswitch or session border controller just before the call leaves the provider's network. It receives the call details, looks up what the provider knows about the customer and the calling number, chooses an attestation level, and signs the resulting PASSporT with the provider's private key.
An STI-AS can be built into an SBC, run as a standalone signing server, or consumed as a hosted service through a SIP redirect or HTTP API. Whatever the architecture, the attestation logic is the important part: it should draw on customer onboarding records, number inventory, and any delegated authority to use numbers the provider does not own.
The authentication service should also record what it signed, including the origid, attestation, and the customer the call was attributed to. Those records are what a provider relies on later when it answers a traceback request or investigates complaints about a particular call stream. Keeping these records for a sensible retention period, and making them searchable by origid and calling number, turns a stressful traceback into a quick lookup.
Why it matters to carriers
The STI-AS is where your compliance policy turns into a signature that other carriers will judge you by. A misconfigured authentication service that defaults to A attestation, or that signs traffic from wholesale customers as if it were your own, can damage your reputation across the industry far faster than you can repair it.