Nametag for Jira Service Management

Overview

Nametag for Jira Service Management (JSM) makes a help desk requester prove who they are — with a government ID and a selfie — before an agent can work their request. It closes the social- engineering gap on high-risk actions such as password resets, MFA recovery, and account unlocks.

When a request is created in a covered project, Nametag:

• Creates a verification request and generates a verification link.
• Holds the issue in a Pending identity verification status, out of agent queues, with the SLA paused.
• Records only the decision, match confidence, and timestamps on the issue after the requester verifies — never their ID images, name, or date of birth.

Verification runs on a phone in about 30 seconds, with no app to download. Results flow back to Jira automatically, and the issue moves to your agent-workable status only when the identity is verified and bound to the reporter.

This is a native Atlassian Forge app and is Cloud only — Server and Data Center are not supported.

How it works

There are three participants:

Participant	Role
Requester	The end user who raised the request and verifies their identity.
Agent	The help desk agent, who only ever sees a verified / not-verified result.
Administrator	Sets up the integration and configures the workflow gate.

The gate is defense in depth: a dedicated status, exclusion from agent queues, an SLA pause, and a Jira workflow validator that blocks the transition to your first agent-workable status until Nametag reports a verified identity. A verified identity that does not match the reporter — or a fraud signal — routes the issue to a Security review status instead of auto-approving.

Administrator setup

You will move between two places: the Nametag console (where you provision the integration) and the Forge app’s administrator page inside Jira (where you paste the Nametag credentials).

1. Prerequisites

• Jira Service Management Cloud with site administrator rights (to install the app and edit workflows).
• Nametag administrator rights on the target environment.
• The Jira Service Management integration enabled for your Nametag organization. It ships off and is enabled per-tenant — if you don’t see the Jira integration option in the console, ask your Nametag contact to enable it.

2. Install the app

1. In Jira, go to Apps → Explore more apps.
2. Search for Nametag Identity Verification and choose Get app / Install.
3. Approve the requested Forge permissions (read and transition issues, read the portal request, and store secrets in Forge secure storage).
4. Open the app’s administrator page under Apps → Manage apps → Nametag and keep it open for step 4.

3. Provision the integration in the Nametag console

1. Open the target environment, then go to Integrations → Jira Service Management.
2. Choose Create integration. This mints, in one step:
   • an environment-scoped API key — the credential the Forge app uses to call Nametag;
   • the nt:jiraservicemanager verification template requesters complete;
   • the environment webhook shared secret used to sign results Nametag sends back.
3. Copy the API key and the webhook shared secret now — the API key is shown only once. If you lose it, use Rotate to mint a new one (rotating invalidates the old key).

4. Connect Jira to Nametag

On the Forge app’s administrator page, paste the values from the console into secure storage: the Nametag URL, Environment ID, API key, and webhook shared secret. These are written to Forge secure storage and are never exposed in issue data or logs.

After saving, copy the webhook URL and OIDC redirect URI that the app displays back into the Nametag console. The redirect URI must be added to the callback allow-list as an exact match — a trailing-slash or path difference is the most common cause of a broken interactive verification.

5. Configure the workflow gate

On the relevant company-managed service project workflow, configure all four layers:

1. Add a Pending identity verification status where new requests land, with the SLA paused and the status excluded from agent queues.
2. Add the identity-verified workflow validator on the transition out of that status. This is the enforceable lock — it blocks the transition until Nametag reports a verified identity.
3. Add a Security review status for verified-but-mismatched or fraud results.
4. Confirm the transition targets: verified → your agent-workable status; mismatch or fraud → Security review.

The workflow validator applies to company-managed projects only. Team-managed projects do not support custom workflow validators, so use company-managed projects wherever verification must be strictly enforced.

6. Per-project settings

On each service project’s settings page you can configure:

• Gate scope — all (every request verifies) or sensitive_only (only selected request types).
• Required request types — when scope is sensitive_only, the request types that trigger verification (for example “Reset MFA” or “Unlock account”).
• Binding strength — how strictly the verified identity must match the reporter.
• Template — the verification template (defaults to nt:jiraservicemanager).
• Delivery — how the verification link reaches the requester: portal, email, SMS, or WhatsApp.

The requester experience

The person who raised the request verifies in about 30 seconds, using only their phone and a government-issued photo ID:

1. Open the request in the help desk portal and tap Verify (the link may also arrive by email, SMS, or WhatsApp).
2. Continue on a phone, scan the ID (front and back if prompted), and take a selfie.
3. See a confirmation and close the window.

Once verified, the request moves out of the waiting state and into the support queue. The help desk only ever sees a verified / not-verified result — ID images, name, date of birth, and other personal details are never stored in the ticket.

Verification links expire after 7 days. If a link expires, the requester reopens the request and starts again, or the agent sends it again.

Troubleshooting

Symptom	Likely cause	Fix
App shows “not connected” / 401 from Nametag	API key wrong, unsaved, or rotated without updating Forge	Re-paste the current API key on the Forge administrator page.
Results never arrive	Webhook shared secret or URL mismatch	Re-copy the webhook shared secret and webhook URL into Forge/Nametag.
Requester taps Verify and hits an error	OIDC redirect URI not on the callback allow-list, or not an exact match	Copy the exact redirect URI from the Forge administrator page into the Nametag allow-list.
Request stuck in “Pending identity verification” over a week	The verification expired after ~7 days	Resend to create a fresh request — expired links can’t be reused.
Verify button never appears	Integration not enabled, project not configured, or a team-managed project	Confirm the integration is enabled, the project/gate scope covers the request type, and the project is company-managed.

If problems persist, contact Nametag support with your environment ID and the affected issue key.