Premiers pas

Présentation

Le protocole et l'API Digital Asset Links permettent à une application ou à un site Web de faire des déclarations publiques et vérifiables sur d'autres applications ou sites Web. Par exemple, un site Web peut déclarer qu'il est associé à une application Android spécifique ou qu'il souhaite partager les identifiants des utilisateurs avec un autre site Web.

Voici quelques utilisations possibles de Digital Asset Links :

• Le site Web A déclare que les liens vers son site doivent s'ouvrir dans une application désignée sur les appareils mobiles, si l'application est installée.
• Le site Web A déclare qu'il peut partager ses identifiants utilisateur Chrome avec le site Web B afin que l'utilisateur n'ait pas à se connecter au site Web B s'il est connecté au site Web A.
• L'application A déclare qu'elle peut partager les paramètres de l'appareil, tels que la position, avec le site Web B.

Termes clés

• Principal : le principal est l'application ou le site Web qui fait la déclaration. Dans Digital Asset Links, le principal est toujours l'application ou le site Web qui héberge la liste des déclarations.
• Liste d'instructions : les instructions sont contenues dans une liste d'instructions qui contient une ou plusieurs instructions. Une liste d'instructions est en texte clair et accessible publiquement, dans un emplacement contrôlé par le principal et difficile à usurper ou à falsifier. Il peut s'agir d'un fichier autonome ou d'une section d'un élément plus volumineux. Par exemple, sur un site Web, il s'agit d'un fichier entier. Dans une application Android, il s'agit d'une section du fichier manifeste de l'application. Les déclarations peuvent être consultées et validées par n'importe qui à l'aide de méthodes non propriétaires. Pour en savoir plus, consultez la documentation sur la liste des instructions.
• Déclaration  : une déclaration est une construction JSON étroitement structurée qui se compose d'une relation (ce que la déclaration dit de faire, par exemple : activer le partage des identifiants) et d'une cible (le site Web ou l'application auxquels la relation s'applique). Par conséquent, chaque instruction est comme une phrase, où principal dit relation à propos de cible.
  
• Consommateur de déclaration : un consommateur de déclaration demande une liste de déclarations à un principal, vérifie la présence d'une déclaration par rapport à un principal donné et, si elle existe, peut effectuer l'action spécifiée. Pour en savoir plus, consultez la documentation sur l'utilisation des relevés.

Exemple d'utilisation rapide

Voici un exemple très simplifié de la façon dont le site Web www.example.com pourrait utiliser les liens Digital Asset Links pour spécifier que tous les liens vers des URL de ce site doivent s'ouvrir dans une application désignée plutôt que dans le navigateur :

1. Le site Web www.example.com publie une liste d'instructions à l'adresse https://www.example.com/.well-known/assetlinks.json. Il s'agit du nom et de l'emplacement officiels d'une liste de déclarations sur un site. Les listes de déclarations situées à un autre emplacement ou portant un autre nom ne sont pas valides pour ce site. Dans notre exemple, la liste des instructions se compose d'une seule instruction, qui accorde à son application Android l'autorisation d'ouvrir des liens sur son site :

   [{
       "relation": ["delegate_permission/common.handle_all_urls"],
       "target" : { "namespace": "android_app", "package_name": "com.example.app",
                    "sha256_cert_fingerprints": ["hash_of_app_certificate"] }
     }]

   Une liste d'instructions accepte un tableau d'instructions entre crochets [ ], mais notre exemple de fichier ne contient qu'une seule instruction. sha256_cert_fingerprints correspond aux empreintes SHA256 du certificat de signature de votre application. Pour en savoir plus, consultez la documentation sur les liens d'application Android.
2. L'application Android listée dans la déclaration ci-dessus comporte un filtre d'intent qui spécifie le schéma, l'hôte et le format de chemin des URL qu'elle souhaite gérer (dans ce cas, https://www.example.com). Le filtre d'intent inclut un attribut spécial android:autoVerify, nouveau dans Android M, qui indique qu'Android doit valider la déclaration sur le site Web décrit dans le filtre d'intent lorsque l'application est installée.
3. Un utilisateur installe l'application. Android détecte le filtre d'intent avec l'attribut autoVerify et vérifie la présence de la liste d'énoncés sur le site spécifié. Si elle est présente, Android vérifie si ce fichier inclut un énoncé accordant la gestion des liens à l'application et valide l'application par rapport à l'énoncé par hachage de certificat. Si tout est en ordre, Android transfère toutes les intentions https://www.example.com vers l'application example.com.
4. L'utilisateur clique sur un lien vers https://www.example.com/chiots sur son appareil. Ce lien peut se trouver n'importe où : dans un navigateur, dans une suggestion Google Search Appliance ou ailleurs. Android transfère l'intent vers l'application example.com.
5. L'application example.com reçoit l'intent et choisit de le gérer, en ouvrant la page des chiots dans l'application. Si, pour une raison quelconque, l'application avait refusé de gérer le lien ou si l'application n'était pas sur l'appareil, le lien aurait été envoyé au prochain gestionnaire d'intent par défaut correspondant à ce modèle d'intent (souvent le navigateur).

Remarques et limites importantes :

• Le protocole n'authentifie pas le compte principal qui fait la déclaration, mais la déclaration se trouve à un emplacement spécifique fortement associé au compte principal et sous le contrôle de celui-ci.
• Le protocole n'authentifie pas la cible de l'instruction, mais il permet à l'appelant d'authentifier la cible (par exemple, une instruction identifie les cibles d'applications mobiles par le hachage du certificat et le nom du package).
• Le protocole n'effectue aucune action d'instruction de manière native. Il permet plutôt d'exposer des instructions qu'une application consommatrice doit valider, puis décider si et comment agir. Android M effectue ces étapes de manière native. Par exemple, si un site Web délègue la gestion des liens à une application spécifique, Android vérifie et valide l'instruction, valide l'application cible, puis propose à l'application de gérer le lien donné.
• Le protocole ne permet pas de faire des déclarations sur deux tiers : c'est-à-dire que le site Web A peut faire une déclaration sur le site Web B, mais pas sur la relation entre le site Web B et le site Web C. Toutefois, si le site B fait confiance au site A, il peut vérifier si le site A a accordé l'autorisation au site C et décider de l'appliquer.

Étapes suivantes

1. Vérifiez s'il existe une documentation explicite pour votre cas d'utilisation.
2. Découvrez comment créer un relevé.