## Trusted Identity Attributes via Claim Mappings Data from JWT claims can be returned from the authentication step as trusted identity attributes for use in binding rule selectors and bind name interpolation. Control of which claims are mapped to which identity attributes is governed by the [`ClaimMappings`](#claimmappings) and [`ListClaimMappings`](#listclaimmappings). These are both maps of items to copy with elements of the form: `"":""`. The only difference between these two types of mappings is that `ClaimMappings` is used to map singular values (such as a name, department, or team) while `ListClaimMappings` is used to map lists of values. The singular values mapped by `ClaimMappings` can be interpolated in a binding rule, and the lists of values mapped by `ListClaimMappings` cannot. Assume this is your config snippet: ```json { "Name": "example-auth-method", "Type": "", "Description": "Example auth method", "Config": { "ClaimMappings": { "givenName": "first_name", "surname": "last_name" }, "ListClaimMappings": { "groups": "groups" } } } ``` This specifies that the values in the JWT claims `"givenName"` and `"surname"` should be copied to attributes named `"value.first_name"` and `"value.last_name"` respectively. Additionally the list of values in the JWT claim `"groups"` should be copied to an attribute named `"list.groups"`. The following table shows the resulting attributes that will be extracted, and the ways they may be used in Rule Bindings: | Attributes | Supported Selector Operations | Can be Interpolated | | ------------------ | -------------------------------------------------- | ------------------- | | `value.first_name` | Equal, Not Equal, In, Not In, Matches, Not Matches | yes | | `value.last_name` | Equal, Not Equal, In, Not In, Matches, Not Matches | yes | | `list.groups` | In, Not In, Is Empty, Is Not Empty | no | ### Claim Specifications and JSON Pointer The [`ClaimMappings`](#claimmappings) and [`ListClaimMappings`](#listclaimmappings) fields are used to point to data within the JWT. If the desired key is at the top of level of the JWT, the name can be provided directly. If it is nested at a lower level, a JSON Pointer may be used. Assume the following JWT claims are decoded: ```json { "division": "North America", "groups": { "primary": "Engineering", "secondary": "Software" }, "iss": "https://my-corp-app-name.auth0.com/", "sub": "auth0|eiw7OWoh5ieSh7ieyahC3ief0uyuraphaengae9d", "aud": "V1RPi2MYptMV1RPi2MYptMV1RPi2MYpt", "iat": 1589224148, "exp": 1589260148, "nonce": "eKiihooH3Fah8Ieshah4leeti6ien3" } ``` A parameter of `"division"` will reference `"North America"`, as this is a top level key. A parameter `"/groups/primary"` uses JSON Pointer syntax to reference `"Engineering"` at a lower level. Any valid JSON Pointer can be used as a selector. Refer to the [JSON Pointer RFC](https://tools.ietf.org/html/rfc6901) for a full description of the syntax