> For the complete documentation index, see [llms.txt](https://docs.payments.thalescloud.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.payments.thalescloud.io/tokenization/es/implement-tokenization/post-tokenization-requests/marco-de-tokens-en-la-nube-de-visa-ctf/vinculacion-del-dispositivo.md).

# Vinculación del dispositivo

Esta función permite al Comercio solicitar al Emisor que apruebe la vinculación entre una tarjeta digital COF y un dispositivo.

El objetivo de esta función es aumentar el nivel de aseguramiento de la tarjeta digital mediante la verificación del usuario final.

El Emisor puede definir opcionalmente reglas para denegar las vinculaciones desde dispositivos considerados inseguros. Si un dispositivo coincide con una o más reglas, D1 deniega automáticamente la solicitud de vinculación. Si el Emisor no define ninguna regla, las solicitudes de vinculación no se deniegan y el Nivel de Confianza permanece `AMARILLO`.

La siguiente tabla enumera las reglas disponibles. Para obtener más detalles, consulte la fase de incorporación de D1.

| Nombre de la regla                          | Descripción                                                                                                           |
| ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| Tipos de dispositivo no confiables          | El Emisor puede seleccionar los tipos de dispositivo en los que no confía. Por ejemplo, dispositivos de tipo `RELOJ`. |
| Fabricante del dispositivo                  | El Emisor puede enumerar los fabricantes de dispositivos en los que no confía.                                        |
| Fabricante del dispositivo - versión del SO | Si se conoce, el Emisor puede especificar una versión del SO en la que no confía.                                     |
| Fabricante del dispositivo - versión del FW | Si se conoce, el Emisor puede especificar una versión de firmware en la que no confía.                                |

{% hint style="warning" %}
**Precaución**

D1 solo puede aplicar estas reglas si VTS envía los campos requeridos. Actualmente, VTS no garantiza ningún conjunto específico de datos del dispositivo. Aunque el Emisor defina una regla, D1 no puede garantizar que la regla se aplique sistemáticamente.
{% endhint %}

D1 gestiona este flujo en nombre del Emisor.

El siguiente diagrama muestra un flujo de alto nivel y destaca la participación del Emisor en el proceso.

<figure><img src="https://3386638856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW6dljaTEEzefPQILRFB7%2Fuploads%2FlaIrDSfwhpCn3I2xhIMo%2FSequence%20Diagram%20%E2%80%93%20Device%20binding.svg?alt=media&amp;token=2e84793a-2bc3-4049-a466-6e3ea1dc085f" alt=""><figcaption><p>Flujo de vinculación de dispositivo de alto nivel.</p></figcaption></figure>

El diagrama hace referencia a [Aprobar con autenticación reforzada](/tokenization/es/implement-tokenization/card-tokenization-request/processing-the-response/approve-with-step-up-authentication.md).

Este es el mismo flujo utilizado para el procesamiento de Tokenización, con las siguientes excepciones:

* El `Servicio de atención al cliente` el método ID\&V no es compatible.
* El `En la aplicación` el método ID\&V puede ser compatible dentro de la aplicación del emisor a través del SDK de D1 (consulte la sección [Autenticación en la aplicación para Visa CTF](/push-provisioning/es/implement-push-provisioning/implement-view-and-control/in-app-authentication-for-visa-ctf.md)) o mediante una API adicional de backend que permite aprobar la vinculación después de que la autenticación se haya completado correctamente. Esto se muestra en el siguiente diagrama:

<figure><img src="https://3386638856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW6dljaTEEzefPQILRFB7%2Fuploads%2FXnICtVVRg7JKQCMvAu4y%2FSequence%20Diagram%20%E2%80%93%20Device%20binding%202.svg?alt=media&amp;token=38db563b-7c3e-4f3a-8294-3a9760824dff" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
**Nota**

Se aplican los siguientes mapeos de campos:

* `tokenReferenceID` = `digitalCardID`
* `deviceIndex` = `deviceReference`
  {% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.payments.thalescloud.io/tokenization/es/implement-tokenization/post-tokenization-requests/marco-de-tokens-en-la-nube-de-visa-ctf/vinculacion-del-dispositivo.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
