--- title: Built-in attributes description: The Trust Framework provides built-in attributes that enable you to use PingOne service and user profile data right out of the box. component: pingone page_id: pingone:authorization_using_pingone_authorize:p1_az_built_in_attributes canonical_url: https://docs.pingidentity.com/pingone/authorization_using_pingone_authorize/p1_az_built_in_attributes.html revdate: April 30, 2026 section_ids: p1_az_built_in_user_attibutes: User attributes p1-aam-attr: API Access Management attributes creating-attributes-from-built-in-attributes: Creating attributes from built-in attributes custom-access-token-claim-attribute: Custom access token claim attribute http-request-header-attribute: HTTP request header attribute api-operation-path-parameters: API operation path parameters p1-token-attributes: Access token-related attributes --- # Built-in attributes The Trust Framework provides built-in attributes that enable you to use PingOne service and user profile data right out of the box. Built-in attributes are nested under the **PingOne** parent attribute on the **Attributes** tab. PingOne Authorize owns the **PingOne** parent attribute and its children. The **Shield** (![pab1683047811271](_images/pab1683047811271.png)) icon indicates that these attributes are system owned and editing restrictions apply. You can't move, update, or delete these attributes. You can't nest your own attributes under the **PingOne** and user **ID** attributes. This ensures that built-in attributes are configured correctly and always available. ## User attributes Built-in **User** attributes model user identity information for use in other attributes and directly in policies. You can nest your own attributes under the **User** attribute. | | | | - | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | * To use built-in user attributes, make sure the [PingOne SSO](../getting_started_with_pingone/p1_p1sso_start.html) service is enabled in your environment. This provides access to user profile information in the [PingOne Directory](../directory/p1_directories_menu.html). * These attributes resolve identities stored in the PingOne Directory and don't access user information in external identity stores. If you're using an external identity store, create your own user attributes that resolve against that store. * When you run test scenarios for these attributes on the **Test** tab, use the **PingOne User** field to simulate a request from any user in the current environment. | ![Screen capture of the Attributes tab in the PingOne Authorize Trust Framework showing the User and ID attributes nested under the PingOne parent attribute.](_images/p1-az-built-in-user-attributes.png) The following built-in user attributes resolve from the `userContext.userId` property of the decision request. These attributes are derived from properties of the PingOne user object. Learn more about the user object in [Users data model](https://developer.pingidentity.com/pingone-api/platform/users/users-1.html#users-data-model) in the PingOne Platform API Reference. | Attribute | Data type | Description | | ---------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **User** | JSON | The `PingOne.User` attribute returns a JSON object that provides data about the identity requesting access to a resource.This attribute retrieves the PingOne user object through the `/environments/{envID}/users/{userID}` endpoint.Learn more about the **PingOne User** resolver in [Resolvers](p1_az_resolvers.html). | | **ID** | String | The `PingOne.User.ID` attribute returns the ID of the identity requesting access to a resource.Learn more about the **PingOne User ID** resolver in [Resolvers](p1_az_resolvers.html). | | **email** | String | The `PingOne.User.email` attribute returns the email address of the identity requesting access to a resource.This attribute uses a JSONPath processor to extract the user's email address from the `PingOne.User` attribute. | | **name** | JSON | The `PingOne.User.name` attribute returns a JSON object that provides the name schema for the identity requesting access to a resource.This attribute uses a JSONPath processor to extract the user's name information from the `PingOne.User` attribute. As an example, consider a user called `Gregory Eric Jones` whose father has the same name. | | **family** | String | The `PingOne.User.name.family` attribute returns the last name of the identity requesting access to a resource.This attribute uses a JSONPath processor to extract the user's last name (for example, `Jones`) from the `PingOne.User.name` attribute. | | **formatted** | String | The `PingOne.User.name.formatted` attribute returns the fully formatted name of the identity requesting access to a resource.This attribute uses a JSONPath processor to extract the user's formatted name (for example, `Mr. Gregory E. Jones, II`) from the `PingOne.User.name` attribute. | | **given** | String | The `PingOne.User.name.given` attribute returns the first name of the identity requesting access to a resource.This attribute uses a JSONPath processor to extract the user's first name (for example, `Gregory`) from the `PingOne.User.name` attribute. | | **primaryPhone** | String | The `PingOne.User.primaryPhone` attribute returns the main phone number of the identity requesting access to a resource.This attribute uses a JSONPath processor to extract the user's phone number from the `PingOne.User` attribute. | | **username** | String | The `PingOne.User.username` attribute returns the username of the identity requesting access to a resource.This attribute uses a JSONPath processor to extract the username from the `PingOne.User` attribute. | Built-in user attributes comprise a subset of the standard and core PingOne user attributes available in **Directory > User Attributes**. You can [generate attributes](p1_az_generating_attributes.html) in PingOne Authorize for standard, core, and custom PingOne user attributes that aren't already built in, and use them in conditions, processors, and rules. ![Screen capture showing User attributes that you can generate in a gray font.](_images/dqj1699033773680.png) Changes made to PingOne user attributes, such as deleting an attribute or changing a custom attribute's description, don't affect the corresponding built-in or generated user attributes in PingOne Authorize, as long as they're in use. Deleting a PingOne user attribute deletes the corresponding attribute in PingOne Authorize if the attribute has no [dependencies](p1az_viewing_dependents.html). Changes made to built-in user attributes in PingOne Authorize don't affect the corresponding PingOne user attributes. For example, changing the name of the built-in **email** attribute to **emailAddress** in PingOne Authorize doesn't change the name of the associated PingOne **email** user attribute. The PingOne Authorize **emailAddress** attribute will continue to work as usual to resolve the user's email address. ## API Access Management attributes API Access Management attributes model API services and operations, HTTP requests and responses, and access tokens. PingOne Authorize generates these attributes when you enable [custom policies](p1az_adding_custom_policies_for_api_services_and_operations.html) for an [API service](p1az_add_api_service.html). ![Screen capture of the Attributes tab in the PingOne Authorize Trust Framework showing API Access Management attributes nested under the PingOne parent attribute.](_images/p1-az-built-in-aam-attrs.png) ### Creating attributes from built-in attributes You can derive your own attributes from built-in API Access Management attributes, as described in the following examples. #### Custom access token claim attribute In the following attribute, a value processor is used to resolve a custom `title` claim from the built-in `PingOne.API Access Management.Identity.Access Token` attribute. To ensure that a token without the custom claim is resolved successfully, the attribute has an empty string as its default value. In this example, the claim's JSON data type is **String**. Access token claims can have other data types, including **Number** and **Collection**. ![Screen capture showing an Access Token attribute resolver and a JSONPath value processor that work together to extract the custom Title claim from the access token.](_images/p1az-built-in-attribute-title-claim.png) #### HTTP request header attribute To allow policy authors to use a custom header in policies, you can define an attribute that extracts a custom header value from an HTTP request or response. In the following attribute, a value processor is used to resolve the `X-Shared-Secret` value from the built-in `PingOne.API Access Management.HTTP.Request.Headers` attribute as a collection. To ensure that a header without the custom value is resolved successfully, the attribute has an empty collection as its default value. ![Screen capture showing a Request Headers attribute resolver and a JSONPath value processor that work together to extract a custom header value.](_images/p1az-built-in-attribute-shared-secret-header.png) #### API operation path parameters If an API operation path includes a parameter, you can define an attribute that allows policy authors to use the parameter in custom policies. For example, the following attribute extracts the user ID from a decision request that matches an API operation defined with the path `/records/user/{userId}`. Learn more about using this attribute in a policy in [Adding custom policies for API services and operations](p1az_adding_custom_policies_for_api_services_and_operations.html). ![Screen capture showing a resolver for the API Access Management Path Parameters attribute working with a JSONPath processor to extract the user ID from the decision request URL.](_images/p1az-built-in-attribute-path-parameters.png) ### Access token-related attributes When you deploy an API service, PingOne Authorize generates a set of attributes based on various access token claims. You can use these attributes in [custom policies](p1az_adding_custom_policies_for_api_services_and_operations.html) for claims-based access control. You can also generate additional attributes for access token claims that aren't already represented by built-in attributes. PingOne Authorize uses the **Authentication Age**, **Authentication Policy**, and **Authentication Time** attributes in basic access control rules for [step-up authentication](../authentication/p1_stepup_authentication_for_apis.html). | Attribute | Data type | Description | | ------------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Authentication Age** | Number | The `API Access Management.Identity.Access Token.Authentication Age` attribute returns the number of seconds since the token issuer authenticated the end user.This attribute uses the `System Current DateTime` resolver and a SpEL processor to calculate the number of seconds since the **Authentication Time**. This calculation requires the `auth_time` claim in the access token. | | **Authentication Policy** | String | The `API Access Management.Identity.Access Token.Authentication Policy` attribute returns the authentication policy that was satisfied when the access token was issued. An authentication policy is also called an authentication context class reference (ACR).If the access token contains an `acr` claim, this attribute uses a JSONPath processor to extract the `acr` value from the `API Access Management.Identity.Access Token` attribute. | | **Authentication Time** | Zoned Date Time | The `API Access Management.Identity.Access Token.Authentication Time` attribute returns the date and time when the token issuer authenticated the end user.If the access token contains an `auth_time` claim, this attribute uses a JSONPath processor to extract the date and time from the `API Access Management.Identity.Access Token` attribute. If the claim is missing from the token, the default value is January 1, 1970. | | **Client ID** | String | The `API Access Management.Identity.Access Token.Client ID` attribute returns the client to which the access token was issued.If the access token contains a `client_id` claim, this attribute uses a JSONPath processor to extract the `client_id` value from the `API Access Management.Identity.Access Token` attribute. | | **Scopes** | Collection | The `API Access Management.Identity.Access Token.Scopes` attribute returns a list of the access scopes included in the token.If the access token contains a `scope` claim, this attribute uses a JSONPath processor to extract the `scope` value from the `API Access Management.Identity.Access Token` attribute. | | **Subject** | String | The `API Access Management.Identity.Access Token.Subject` attribute returns the user (resource owner) represented by the token.Some token issuers populate the `sub` claim with a client ID when the Client Credentials grant type is used and there isn't an individual resource owner.If the access token contains a `sub` claim, this attribute uses a JSONPath processor to extract the `sub` value from the `API Access Management.Identity.Access Token` attribute. |