https://cms.semweb.pro/talk/18411248 https://cms.semweb.pro/talk/18411248 https://cms.semweb.pro/talk/18411248 <p><a href="https://solidproject.org/">Solid</a> est un ensemble de spécifications qui définissent un contrôle d'accès appliqué aux données liées. L'une des utilisations phares est la constitution de stockages de données personelles, permettant de donner à une personne le contrôle du partage des données la concernant. Le contrôle d'accès est exprimé dans Solid de deux manières possibles, <a href="https://solidproject.org/TR/wac">WAC</a> (Web Access Control) et <a href="https://solidproject.org/TR/acp">ACP</a> (Access Control Policy), et c'est ce dernier sur lequel cette présentation va se concentrer.</p> <p>Le contrôle d'accès via ACP est centré sur l'identité, materialisée par le <a href="https://w3c.github.io/WebID/spec/identity/index.html">WebID</a>, et déléguée à un composant du système selon les normes du domaine (à savoir <a href="https://solidproject.org/TR/oidc">Solid-OIDC</a>, une extension de <a href="https://openid.net/">OpenID Connect</a>). Selon les cas d'uilisation, trois approches de Solid-OIDC sont possibles, toutes ayant pour résultat l'obtention par le client d'un jeton d'identité portant la signature cryptographique de son émetteur, ce qui permet au client d'accéder au nom de leur propriétaire à des resources protégées (autrement dit, des données sur son stockage personnel).</p> <p>Une fois la requête authentifiée, le graphe de permission ACP est évalué pour autoriser ou non l'accès. En plus de ses mécanismes de base, ACP définit des points d'extension via lesquels définir de nouveaux attributs d'évaluation des permissions. Sur ce point d'extension ont été définies les Access Requests/Access Grants. Celles- forment un mécanisme formalisant la demande et l'autorisation d'accès à une ressource par un échange de <a href="https://www.w3.org/TR/vc-data-model/">Verifiable Credentials</a>. Les Access Request/Access Grants répondent à un principe de moindre permission, en créant un contexte privilégié unifié dans lequel le propriétaire de donnée peut autoriser l'accès à ses ressources de manière temporaire et facilement révocable, qui permet à un parti non-privilégié d'obtenir l'accès à des resources sans avoir besoin de modifier les métadonnées d'accès.</p> <p>L'objet de cette présenation sera de couvrir les modes d'authentification définis par Solid-OIDC selon les cas d'utilisation, et d'expliquer comment ceux-cis s'articulent avec les Access Requests et Access Grants.</p> <p>L'auteur: Nicolas Seydoux, ingénieur chez <a href="https://www.inrupt.com/">Inrupt</a>. Je suis particulièrement impliqué dans la conception et le développement d'outils à destination des développeurs pour permettre la création d'applications basées sur les standards de Solid, avec un intérêt tout particulier sur l'authentification et l'autorisation. Les librairies développées par Inrupt pertinentes dans le cadre de cette présentation incluent <code>@inrupt/solid-client</code>, <code>@inrupt/solid-client-access-grants</code> , <code>@inrupt/solid-client-authn-node</code> et <code>@inrupt/solid-client-authn-browser</code> sur NPM en Javascript, et <code>com.inrupt.client:inrupt-client-bom</code> sur Maven Central en Java. Des démonstrations de l'utilisation de ces différentes libraries sont données dans <a href="https://docs.inrupt.com/">notre documentation</a>.</p> <p>Le <a href="https://homepage.zwifi.eu/slides/2024/semwebpro/">support de présentation</a> est en ligne.</p> 2024-11-21T22:53+00:00 admin