Aller au contenu
Universal Commerce Protocol Universal Commerce Protocol Protocol registry / fr
Le standard UCPUCP vs ACPImplémenterCommerce agentiqueFramework
ConceptGEOllms.txtLexiquePaiement agentiqueAP2Visa et MastercardCommerce agentique B2BMéthodologieCas d'usagePourquoi maintenantPour quiManifesteFAQRessourcesSourcesÉcosystèmeValidateurDiagnostic readinessÀ proposContact
EN Lancer le diagnostic →

Note de référence

Identity Linking UCP : relier un compte avec OAuth

Fonctionnement d'Identity Linking dans UCP : niveaux d'accès, découverte OAuth, scopes, consentement et repli sans authentification.

Publiée le . Rattachée à le guide d'implémentation UCP.

Identity Linking permet à une plateforme UCP d’agir avec le compte marchand d’un utilisateur, après consentement explicite. La version actuelle s’appuie sur OAuth 2.0 hébergé par le marchand et distingue trois niveaux d’accès.

En bref

  • Les accès sont publics, authentifiés comme agent, ou authentifiés comme utilisateur.
  • OAuth gère l’identité ; UCP donne un sens commercial aux scopes.
  • L’absence d’Identity Linking ne retire pas une capacité de la négociation.

Quels sont les trois niveaux d’accès ?

La spécification Identity Linking distingue :

Niveau Authentification Exemple
public aucune parcourir un catalogue public
agent-authenticated identifiants de plateforme créer un panier invité
user-authenticated plateforme et jeton utilisateur adresses ou commandes personnelles

Identity Linking fait le pont entre les deux derniers niveaux. La plateforme obtient un jeton après le consentement du client, puis le présente aux opérations protégées.

Comment UCP et OAuth se partagent-ils le travail ?

UCP définit les scopes commerciaux et les opérations qu’ils protègent. OAuth définit les points de terminaison, les flux, les jetons et le vocabulaire accepté par le serveur d’autorisation. Les deux couches se complètent mais ne se confondent pas.

Le marchand publie ses métadonnées OAuth selon RFC 8414. Une ressource protégée peut répondre 401 avec WWW-Authenticate et un lien resource_metadata vers /.well-known/oauth-protected-resource. La plateforme construit ensuite sa propre requête d’autorisation, avec son state, son redirect_uri et ses valeurs PKCE.

Un continue_url ne doit pas transporter une requête OAuth préfabriquée. Il sert aux étapes hébergées hors OAuth, comme la création d’un compte ou l’acceptation de conditions.

Comment déclarer les scopes ?

config.scopes dans le profil UCP déclare les barrières obligatoires. Le document OAuth scopes_supported liste tout le vocabulaire accepté. Les scopes acceptés mais absents de config.scopes peuvent débloquer des fonctions optionnelles sans rendre l’authentification obligatoire.

Les messages d’exécution peuvent signaler identity_optional lorsqu’une connexion améliorerait la réponse. L’agent peut alors proposer le lien de compte sans bloquer un parcours invité valide.

La négociation de capacités reste indépendante

Une capacité n’est jamais retirée de l’intersection parce qu’Identity Linking manque. Si Order est annoncé des deux côtés, il reste négocié. Les scopes déclarent ensuite quelles opérations exigent un jeton utilisateur.

Cette séparation est essentielle pour la compatibilité. Une plateforme peut utiliser le catalogue public ou un checkout invité, même si elle ne sait pas encore lier un compte. Le marchand ne doit pas transformer une absence d’identité en incompatibilité générale du protocole.

Traitement d’une identité requise

  1. La plateforme appelle l’opération sans jeton.
  2. Le marchand répond 401 et fournit les métadonnées de ressource.
  3. La plateforme découvre le serveur d’autorisation.
  4. Le client donne son consentement dans l’interface du marchand.
  5. La plateforme échange le code avec PKCE.
  6. Elle rejoue l’opération avec le jeton et les scopes accordés.

Un jeton insuffisant doit produire une erreur distincte d’une absence de jeton. Les logs doivent conserver le scope demandé et le scope obtenu, sans enregistrer le secret.

Checklist de sécurité

  • héberger OAuth sous le domaine du marchand ;
  • publier les métadonnées RFC 8414 et RFC 9728 ;
  • utiliser PKCE et vérifier state ;
  • demander le minimum de scopes ;
  • ne jamais placer un jeton dans continue_url ;
  • prévoir un parcours invité lorsque la capacité le permet ;
  • révoquer et renouveler les jetons selon la politique OAuth du marchand.

Le point de découverte UCP lui-même est détaillé dans le manifeste /.well-known/ucp. L’intégration complète est cadrée dans le guide marchand.

Sources

Revenir à le guide d'implémentation UCP · Toutes les notes · Read in English