Résumé

  • La révision 05 du projet individuel APM ajoute une section IPR mentionnant deux demandes de brevet américaines en instance et une éventuelle licence à des conditions raisonnables et non discriminatoires ; il s’agit des affirmations du document, non de conclusions indépendantes.
  • Cette section renvoie au Datatracker pour les divulgations faisant autorité. Or la requête officielle portant exactement sur ce projet renvoyait zéro relation au 13 septembre 2026. Ce constat de base de données ne permet pas d’exclure un autre identifiant, un dépôt en cours ou un décalage d’indexation.
  • Daniel Kade propose un dossier à deux registres : figer la révision technique, puis la relier à la divulgation formelle, modifiable et traçable. C’est une proposition éditoriale, pas une règle de l’IETF.

Le vide à surveiller se trouve entre deux documents

Un responsable d’implémentation qui ne lirait que le texte de la révision 05 disposerait déjà d’informations substantielles. La nouvelle section « IPR Considerations » affirme que certaines techniques décrites sont, ou pourraient être, couvertes par deux demandes de brevet américaines en instance. Elle désigne Sanctum SecOps LLC comme propriétaire et Brian Vicente comme inventeur, puis envisage un accord écrit distinct selon des conditions raisonnables et non discriminatoires pouvant comporter des frais ou redevances.

Il faut conserver les verbes d’attribution. BTW Media n’a pas vérifié la titularité, la validité, la portée, le caractère essentiel, la contrefaçon ou l’opposabilité des droits évoqués. Les numéros de demandes ne sont pas rendus publics dans la note. Celle-ci limite en outre son engagement déclaré aux « Necessary Patent Claims » et exclut notamment des fonctions facultatives, extensions propriétaires, mises en œuvre non conformes, produits sans rapport, plans de contrôle hébergés, services managés, secrets d’affaires et revendications hors périmètre. Réciprocité, suspension défensive et recours restent possibles.

La publication du projet n’accorde aucune licence.

La difficulté n’est donc pas l’absence de toute information. C’est la coexistence de deux supports dotés de cycles de vie différents. La note affirme que les divulgations enregistrées dans le Datatracker restent déterminantes. Pourtant, au terme du relevé, la requête iprdocrel ciblée répondait HTTP 200, avec total_count: 0 et une liste vide pour ce nom exact.

Cette observation ne signifie ni « aucun brevet », ni « aucune déclaration », ni « manquement ». Une déclaration peut être en préparation, associée à une autre référence ou retardée dans l’interface. Le seul énoncé solide est plus modeste : le lien consultable entre ce projet précis et une fiche IPR n’était pas présent à l’heure du relevé.

Pourquoi le registre séparé compte

La page IPR de l’IETF et ses instructions de dépôt organisent une divulgation formelle. Le BCP 79, RFC 8179, prévoit des procédures pour les informations de droits et les déclarations de licence, ainsi que leur mise à jour ou leur retrait. Il indique aussi que les informations IPR et les conditions précises de licence ne devraient pas être intégrées aux RFC ou aux contributions IETF : la page de divulgation en ligne est le point de consultation.

Cette architecture sépare utilement la preuve historique de la révision et le dossier institutionnel vivant. Le fichier 05 permet de savoir ce qui a été écrit, quand et sous quelle empreinte. La fiche de divulgation doit permettre de suivre une identité de dossier, l’autorité du déclarant, les références de demandes ou leur caractère non public, la promesse de licence et ses évolutions.

L’IETF ne tranche toutefois ni la validité ni la portée des droits signalés et ne décide pas si des conditions données satisfont réellement au critère RAND. L’existence future d’une fiche ne vaudrait donc pas décision juridique. Symétriquement, l’absence observée aujourd’hui ne permet pas de conclure à une violation du BCP 79. Les faits disponibles ne suffisent pas pour déterminer qui devait agir, à quel moment et selon quelle qualité.

L’étiquette « Standards Track » n’est pas une adoption

Le Datatracker a enregistré la révision 05 le 13 septembre 2026 à 05:37:48 UTC. Son historique et l’état fourni par l’API décrivent un Internet-Draft individuel actif, sans stream, sans Area Director responsable et sans statut RFC visé consigné par le Datatracker. L’en-tête du fichier dit « Intended status: Standards Track » : c’est l’intention des auteurs, pas l’adoption par un groupe de travail, l’approbation de l’IESG ou la publication d’un RFC. Le remplacement de « Network Working Group » par « Web Authorization Protocol » dans l’en-tête courant n’accorde pas davantage de mandat institutionnel.

Le mécanisme proposé reste techniquement digne d’attention. Pour chaque requête privilégiée, APM ferait examiner la clé liée à un certificat client ou à DPoP, le jeton d’accès et une attestation d’état de l’appareil protégée en intégrité. Le serveur pourrait autoriser, réduire la portée, limiter les méthodes ou refuser entièrement. La traduction d’une dégradation d’état en décision est laissée à l’implémentation ; réduire une portée renforce la décision locale sans modifier ni révoquer le jeton d’origine.

Les RFC sur OAuth mTLS, DPoP, les Rich Authorization Requests et l’identification de l’émetteur fournissent le voisinage normatif. Leur statut ne se transmet pas à APM. Il ne permet pas non plus de savoir si une réalisation d’APM mettrait en œuvre une revendication particulière.

Enfin, la révision conserve une mention d’une implémentation expérimentale en Go, privée jusqu’à la fin du passage de relais aux conseils juridiques, et propose un type authorization_details encore non attribué. Ce sont des indices de travail en cours, non des preuves d’interopérabilité ou d’enregistrement.

Un dossier de droits avec une jointure explicite

Daniel Kade propose un dossier de droits d’implémentation à deux registres. Le premier fige l’objet technique : nom, révision, horodatage, empreintes du texte et du XML, statut de processus, sections concernées, mécanisme et état de l’implémentation. Le second suit la fiche formelle : identifiant Datatracker, déposant et qualité pour agir, références de brevets ou état non publié, titulaire déclaré, engagement de licence, exclusions, réciprocité, suspension défensive, mises à jour et retraits.

La jointure doit relier ces deux plans à une décision concrète : sections techniques potentiellement touchées, solutions de remplacement, revue du conseil, propriétaire interne, décision de prototype, d’achat ou d’adoption, degré de confiance, questions ouvertes et déclencheur de réexamen. « Pas encore lié » doit exister comme état propre ; il ne doit jamais être automatiquement transformé en « aucun droit ».

Le Policy Mirror de Heng Lu invite à préserver l’acte publié tout en rendant visible la couche de décision. La Minimum Initial Specification privilégie une base commune réduite et des choix ultérieurs locaux. Pourquoi BTW Media existe impose enfin de distinguer le signal, l’autorité qui le porte et ce qui demeure inconnu.

Sources

  1. Fiche Datatracker d’APM
  2. Historique du projet APM
  3. Fiche API Datatracker d’APM
  4. Révision 05 d’APM
  5. Révision 04 d’APM
  6. Différence entre les révisions 04 et 05
  7. Requête Datatracker des relations IPR d’APM
  8. Processus de propriété intellectuelle de l’IETF
  9. Instructions IETF pour les divulgations IPR
  10. RFC 8179 : droits de propriété intellectuelle dans les technologies IETF
  11. RFC 8705 : OAuth 2.0 Mutual-TLS
  12. RFC 9449 : OAuth 2.0 DPoP
  13. RFC 9396 : OAuth 2.0 Rich Authorization Requests
  14. RFC 9470 : identification de l’émetteur du serveur d’autorisation OAuth
  15. Source XML de la révision 05
  16. The Policy Mirror
  17. Minimum Initial Specification
  18. Why BTW Media Exists