# Asset Level Credentials
5\. The Asset Level Credentials screen is displayed. This screen allows you to define the access rules at the asset level. For a better understanding of how access credentials work, please check this link.
6\. The **Access Rules** group is displayed. Using the fields in this group, you can decide who is allowed or denied access to the asset. The rules are based on web3 addresses.
7\. The "**Allow ETH Address"** option enables the user to define who can access the asset:
* To grant access to everybody, select "*Allow all addresses*"
* To restrict access to specific users, select "*Allow specific addresses*".
* A text field is displayed. Enter the web3 address and press *Add new address*. You can add multiple addresses.
8\. The "**Deny ETH Address"** option enables the user to define who is denied access to the asset:
* To deny access to everybody, select "*Deny all addresses*"
* To deny access to specific addresses, select *"Deny specific addresses"*.
* A text field is displayed. Enter the web3 address and press *Add new address*. You can add multiple addresses.
**Note:** Selecting both "Allow all addresses" and "Deny all addresses" simultaneously will result in access being denied to all users, as the deny list takes precedence.
9\. To enable access rules based on SSI credentials, select the "Enable SSI Policies" checkbox. The SSI Policies group is displayed.
Using this user interface, the publisher can define access rules at the asset level based on the Verifiable Credentials (VCs) owned by the consumer in their SSI wallet. The VC-based access rules are referred to as SSI policies or simply policies. Three types of SSI policies can be defined:
* **Policies applied to all requested VCs (static policies)**: their scope includes all requested VCs. The following static policies can be applied:
* *signature*: verifies the signature of the VC
* *not-before*: verifies the credential is not used before its validity time
* *revoked-status-list*: verifies that the credential was not
* *expired*: Verifies that the credential has not expired
* signature\_sd-jwt-vc: verifies the signature for the selective disclosure JWT (SD-JWT) type of VCs.
**Note**: by default, certain policies are enforced by the marketplace and are preselected. Additionally, the component that evaluates the submitted VCs applies a set of predefined policies automatically. Therefore, even if you manually deselect a default policy, it may still be enforced due to underlying system rules.
* **Policies applied to a specific VC**: applicable only to the VC for which they were defined. The following policies can be applied to the VC level:
* *Static policies* (see the list above)
* *Allowed issuer:* verifies that the VC was issued by a list of specific entities defined by their DIDs. If the VC was not issued by any of the DIDs in the list, the policy fails
* *Custom policy:* verification rules based on the fields within the requested VCs. For instance, the publisher can enforce a rule that only legal entities from Germany can access the asset. This policy verifies that the `credentialSubject.gx:headquartersAddress.gx:countryCode` equals `"DE"`.
* *Custom URL policy*: A custom policy authored in the REGO language and hosted at a designated URL. This approach enables advanced verification scenarios by allowing tailored logic based on the specific fields within the requested Verifiable Credentials (VCs).
* **Advanced policies:** applicable to all VCs. The following advanced policies can be applied:
* *Credential presenter same as credential owner:* verifies that the entity that issues the verifiable presentation (VP) that embeds the VC is the same as the subject of the VC. In case the entity that submits the VP for verification is not the subject of the VC, the policy fails.
* *All requested credential types are necessary for verification:* verifies that all requested VCs are submitted for verification. If this policy is not enabled and the access rules to the asset request, for instance, two VCs - LegalPerson and LegalRegistrationNumber - a consumer who submits just one of the of these credentials passes the verification. With the policy enabled, passing just one of the credentials will result in failure.
* *Minimum number of credentials required*: Set the minimum number of credentials that must be presented for successful verification. Presenting less VCs than the minimum number of credentials will result in failure.
* *Maximum number of credentials required*: Set the maximum number of credentials that must be presented for successful verification.
**Note**: some of the advanced policies are enforced by default by the marketplace and are checked in the user interface.
10\. **Policies applied to all credentials:** To add a new policy applied to all credentials, mark the corresponding checkbox.
11\. **Policies applied to a specific VC**: To define policies applicable to a particular VC, perform the following steps:
* Click the **New Credential Request** button. The **Credential Request #1** group is displayed.
* From the **Type** list, select the VC you want to be requested. The list of supported VCs will be periodically updated. Please consult here the list of supported VCs. \
From the **Format** list, select the format in which the VC should be presented: `jwt_vc_json`, `mso_mdoc` or `vc+sd_jwt`.
* To apply a static policy to the requested VC, perform the following:
* click on **Add policy** button and from the list select **Static Policy**.
* The **Static Policy** list is displayed. Select a static policy from the list.
* To apply the Allowed issuer policy to the requested VC, perform the following:
* click on **Add policy** button and from the list select **Allowed Issuer**.
* The allowed-issuer policy is diplayed. Press the **New Issuer DID** button and in the **Issuer DID** field enter the DID of the issuer. You can add multiple entries by pressing the **New Issuer DID** button.
* To apply a custom policy to the requested VC, perform the following:
* click on **Add policy** button and from the list select **Custom Policy**.
* The **Name** field is displayed. Enter a meaningful name for the custom policy, using letters and numbers. \
For consistency and readability, it's recommended to use camelCase notation when naming your policy.
* To create a new rule, click the **New rule** button. From the **Credential field** list, choose a field from the selected VC that you want to evaluate. \
Next, select the appropriate operator from the **Operator** list.
\
Finally, enter the desired value in the **Value** field.. Please note that for strings, the comparison is case-insensitive (e.g. "DE", "de" and "De" have the same value).\
You can add multiple rules in the same custom policy.
* To apply a custom policy available at a URL, perform the following:
* click on **Add policy** button and from the list select **Custom URL Policy**.
* The UI group for Custom URL policies is displayed. When using custom URL policies, ensure you follow these guidelines; otherwise, they will not work.
* Enter the policy name in the **Custom URL Policy Name** text field
* Enter the URL where the policy is located in the **Policy URL** text field
* If the custom policy needs arguments to run, to add them, click on the **New argument** button
* Add the parameter name in the **Parameter Name** field and its value in the **Value** field. You can add multiple parameters.
12\. **Advanced Policies.** To set up advanced features related to how the verification of the presented VC is done, perform the following steps:
* Select the **Edit Advanced Policy Features** checkbox. The **Advanced SSI Policy Features** group is displayed.
* Some advanced features are selected by default when the group is displayed.
* Please select the policies relevant to your case. For both the minimum and maximum number of credentials required, enter a numerical value as illustrated below.
**Note**: Ensure you understand the function of the advanced policies and how they impact the verification process of VCs for the respective asset.
13\. Press the **Continue** button.
