Claim disclosure

ProAuth keeps trusted authentication and authorization context separately from claims returned to applications. Issuer extension claims are permitted by OpenID Connect; this separation makes their disclosure predictable and minimizes application data.

Permission and requests

A claim rule grants permission to disclose a claim at specified destinations. A scope or claims request selects among permitted results. Requests never restore filtered values or add destinations.

Rule outcome	Not requested	Requested
Filtered out or not permitted	Omitted	Omitted
Always	Included	Included
WhenRequested	Omitted	Included

Availability, consent, authorization and applicable value constraints still apply. An explicitly configured Always claim does not require a request. WhenRequested is supported for ID tokens and UserInfo. Access-token contents remain a client/resource policy decision; request-conditioned access-token rules are rejected. There are no custom scope mappings.

Standard scopes retain their standard claim sets. profile does not request raw fed_* claims. Scope-based ID-token profile selection applies to the ID-token-only response; other flows obtain these scope-selected claims at UserInfo. The standard claims parameter can independently request ID-token and UserInfo claims. See OIDC Core.

Default rules and editions

The default rules permit the following claims at ID-token and UserInfo destinations only when requested:

Claims	Source	How to request
Standard profile claims	User profile	Applicable standard scopes or exact names in claims
pa_iss_customer, pa_iss_subscription, pa_iss_clientapp, pa_iss_tenant, pa_iss_idp_scheme	Trusted issuer context	Exact names in claims
Available fed_* claims	Authentication pipeline	Exact names in claims

Starter and Business editions use these fixed rules without requiring claim-rule customization. Enterprise uses persisted, editable rules: generated defaults include these permissions, but existing customer rules are preserved and do not automatically receive the new permissions. Enterprise administrators can add, restrict or remove them.

For example, pass this JSON as the authorization request's claims parameter:

{
  "id_token": { "pa_iss_subscription": null },
  "userinfo": { "fed_email": null }
}

With the default rules, the ID token can contain the canonical subscription identifier and UserInfo can contain the upstream email if available. Each claim is disclosed only at its requested destination. Neither claim is added to the access token by this request. Claim names must be exact: pa_iss_* and fed_* are not request wildcards, and profile does not select either family. Credential claims and private protocol state remain excluded, including federated forms such as fed_refresh_token and fed_client_secret.

The separate default capability rule continues to forward enabled ProAuth capabilities. The AdminApp also has its narrowly scoped subscription-selector rule.

Rule inputs

The v2 rule DTO and editor expose InputSource and DisclosureMode.

Input source	Value	Available claims
Pipeline	0	The preceding priority group's results; the first group receives authentication source claims without private protocol state or issuer context
IssuerContext	1	Canonical available pa_iss_* values from trusted authorization context
UserProfile	2	Available standard user-profile claims, even without a request

Existing rules use Pipeline and Always (value 0). Their wildcard inputs do not expand to include issuer context. An issuer-source rule must be a filter: select claim names/values and destinations, without generating or replacing issuer values. Forged reserved outputs are rejected. Later priority groups can remove selected issuer claims.

Rules execute in ascending priority groups. Outputs within a group are combined. Ordinary and federated transformations remain supported. Conditions follow transformed claims and are evaluated against final claim names. Source retains destination and condition metadata; None permits intermediate transformation results without external output.

Destinations

Existing serialized values keep their meaning. In particular, Both does not include UserInfo.

Destination	Value
None	0
AccessToken	1
IdentityToken	2
Both (access token and ID token)	3
Source	4
UserInfo	5
AccessTokenAndUserInfo	6
IdentityTokenAndUserInfo	7
All	8

UserInfo requires an explicit UserInfo destination. Merely requesting a claim does not make it available there.

Configuration examples

The following field sets describe v2 filter rules. Supply the usual subscription/client/tenant assignments, active flag, priority and concurrency fields. Use the normal import/export tooling's v2 ClaimRule resources when transporting configuration.

Purpose	InputSource	TypeEvaluationRule	Destination	DisclosureMode
Subscription issuer identifier in ID tokens	IssuerContext	^pa_iss_subscription$	IdentityToken	Always
Selected upstream department at UserInfo	Pipeline	^fed_department$	UserInfo	Always
Email included without a request	UserProfile	^email$	IdentityTokenAndUserInfo	Always
Email only when requested	UserProfile	^email$	IdentityTokenAndUserInfo	WhenRequested

Use RuleType=Filter and FilterTarget=Type for these examples. Rules in later groups must forward the desired earlier results as needed. Do not add a final broad forwarding rule that defeats intentional filtering.

In the Enterprise AdminApp, open Claim rules and create or edit a rule. Select its input source, destination and disclosure mode, then set the claim-name filter and assign the rule to the intended client application.

This example permits the subscription identifier from trusted issuer context in Customer Portal ID tokens, even without an explicit claim request:

In Match source claims, choose Type and enter ^pa_iss_subscription$ as the type evaluation rule:

For requested-only email, select Standard user profile, ID token and UserInfo, and Include when requested. The application must request email at the appropriate destination; assigning this rule alone does not disclose it on every sign-in.

Match the exact email claim with the type evaluation rule ^email$:

Protocol requirements such as authoritative sub, issuer, audience, timestamps, nonce and hashes are enforced separately. auth_time and essential constrained acr have claim-specific rules; essential: true does not universally require returning every claim or failing the request.

GetIssuer*Id APIs return optional disclosed claims and can return null. Request the exact identifier when using the defaults; with custom Enterprise rules, also ensure an issuer-context rule permits it at the required destination.

See upgrade guidance before deploying this change.