...
When fetching data from a resource uri instead of the JWT token, you just need the resource uri(s). The exact URI will be provided by your identity provider. For an OIDC complant identity provider, the data will be provided on a /userinfo endpoint (See also: OIDC Specification, UserInfo endpoint). It is expected that the resource URI returns a JSON data structure.
When specifying a resource uri data source, you will have to select which authentication method is used for the resource URI. Please select the appropriate one based on your identity provider's manual. If the manual doesn't provide clear instructions, or when you are implementing an OIDC compliant authentication on a /userinfo endpoint, select "bearer" (see also: RFC 6750).
...
Beside using the resource URI to retrieve identification data, you could also use the resource URI to check (or document in the audit trail) e.g. product version information, in case such is provided. Below you find an example where a /license endpoint provides the product version information.Please note that all information about the license will then be shown in the audit trail. Find more information below
Data Mappings
For data retrieved from a resource uri, you can define data mappings. Data mappings allow the sender to define expected values, or when used for identification purpose to update recipient information with data provided by the OAuth 2.0 / OIDC identity provider. This can be e.g. in case of an eID provider a confirmed identity number.
To set up such a validation data mapping, or in case of an identity provider where the sender doesn't know the expected value to set up an update mapping, add a Field mapping to the resource URI. The "field property path" is the key of the returned JSON structure of the resource uri. In case of a simple key-value mapping in the JSON, it's just the key (e.g. "given_name"). In case of complex entities returned in the JSON datastructure, the field property path can be a field selector (e.g. "validated_data.given_name") Select the type of field mapping (validate or update), and specify against which data field the retrieved value should be compared (or which data field should be updated with data from the identity provider).
You can set up custom data input fields for validation rules, which means the sender has to provide the expected value in a separate input field. Since eSAW 21.31 you can also use the predefined data fields to validate against (e.g. the recipient mail address, or certain disposable certificate holder information fields). For udpate-rules, of course only the update of predefined fields is available.
OpenID Connect (OIDC) with JWT (JSON Web Token) 
...
Additionally you can add the Field property path. Afterwards, you can choose if you want to validate or update the data. Then you can choose the WorkstepData_Change (in this case the recipient email address was chosen). Please note that you can only validate, but not update the email address!
Data Mappings
Data mappings for data retrieved as claims of the JWT token work similar to the data mappings of the resource uri described above. Note that eSignAnyWhere up to (including) version 21.31 does NOT support addressing elements within complex data structures in the JWT.
Sending an Envelope with OAuth 2.0 / OIDC authentication
...