IDéNum Américain ?

Ci-dessous ensemble de documents relatifs à l’identité sur internet aux USs :

http://www.scribd.com/collections/3191089/Internet-Identity-Ecosystem

(pas encore eu le temps de lire, mais à voir dans quelle mesure cela se ramène à un identifiant unique, ou plus au concept « m account » gérés par plusieurs organisations et utilisés (leurs numéros) dans aucune transaction, comme proposé dans le « modèle » )

Sur le « même » sujet : IDéNum une mauvaise idée ?

IDéNum, une mauvaise idée ?

— quel jeu de mots vaseux

— certes mais le terme coolo franchouille l’appelait aussi quelque peu non ? Mais on peut préférer « Orchidée fixe » (RroseSélavy) par exemple, c’est vrai ..

Enfin bref, donc :

Au sujet de la présentation et proposition ci dessous :

Lancement du label IDéNum (copie locale)

Disponible sur :

http://www.telecom.gouv.fr/actualites/1-fevrier-2010-label-idenum-identite-numerique-multi-services-2311.html

Pour résumer en quelques mots :

• Les « internautes » ont aujourd’hui besoin de multiples login/passwords pour se connecter à de multiples services, privés ou administratifs
• De multiples usurpations d’identités, piratages d’ordinateurs, 33% même mot de passe pour plusieurs services, 55% mots de passe écrits quelque part
• 27% des internautes n’utilisent pas l’administration électronique de peur de piratage des données personnelles
• 56 000 sites de phishing à l’international (faux sites permettant, si un utilisateur s’y connecte, de récupérer un de ses login/passwrd usuels)
• Pour améliorer tout ça il faut utiliser des « certificats » (sorte de mots de passe choisis par une machine (du service) puis enregistrés sur une machine ou carte de l’ « internaute » en vue de future connections), très bien
• Principe proposé : la liste des certificats de l’internaute stockée sur clé USB, carte à puce, ou téléphone mobile !!
• Or tout cela se casse, se perd, se change, se vole, se transfère, se fusionne, se sépare, se backup, se débackup, se rebackup, un peu comme si la liste des actions achetées sur un compte titre était écrite sur votre carte bleue et uniquement là !! Quel délire .. Et en plus pour des « certificats », que l’on utilise genre une fois par an pour déclarer ses impôts, en essayant de retrouver le dit certificat sur le PC ou Mac de l’an dernier ..
• Image :

• Solution idéale et « dématérialisée » ! Pourquoi pas « virtuelle » ? Curieux …

— Il est clair que cela ne fonctionnera pas (7eme bullet avant l’image), sans compter que beaucoup de gens ne comprennent pas ces histoires de « certificats ». Quoi « certificats » ? Certificat d’études ?
— Par contre les constats et le besoin sont clairement là.

— Ça ne peut fonctionner qu’avec une notion de tiers de confiance pour ces informations (écritures), c’est à dire quelque chose comme les « m accounts » et organisations associées, qui ne font que ça, et ont une interdiction stricte d’y regarder ou bien sûr d’en vendre le contenu.

D’autre part :

• Vu que ça ne fonctionnera pas les listes de login/passwords se retrouveront chez facebook, Google, OpenID ou autre (déjà plus ou moins le cas si on le souhaite), si ce n’est l’utilisation directe d’un compte de ces organisations.
• Les certificats très bien, mais plutôt appeler ça « comptes », « login-infos » ou autre (enfin à voir)
• Le but ne doit être — en aucune manière — d’utiliser un même ID pour chaque utilisateur sur tous les services (ça n’est pas forcément ce que suggère la proposition, mais le nom le laisse plus ou moins entendre, et est compris comme cela, pareil pour OpenID d’ailleurs (où pour le coup c’est plus ou moins vraiment le cas, aussi pour facebook)), et voir « position statement IEEE » mentionné dans la page à propos.
• Le numéro d’un compte « m account » n’a besoin d’être utilisé dans aucune transaction (exemples), par contre les infos de comptes de services et login/passwrd ou certificats associés sont écrites sur le compte (le compte est la clé USB ou téléphone dans le cas de la proposition)

En d’autres termes sans doute des choses valides dans cette proposition (et concepts/normes/code(logiciel) existants autour des certificats et accès aux sites associés), ainsi que vrais besoins et nécessité de solution.

Mais le fait de croire que les listes d’infos de comptes peuvent être écrites uniquement sur un quelconque appareil, constitue de toute évidence un défaut rédhibitoire à sa mise en place (et nom à revoir).

D’autre part la proposition n’adresse en rien le véritable point critique de la problématique, c’est à dire  la mise en place des tiers de confiance et comptes associés. C’est à dire la définition d’un nouveau rôle/licence de rôle, et non d’un label.

De manière générale, l’urgence est dans une séparation claire entre entités maintenant les données personnelles des utilisateurs, et entités fournissant les services associés à ces données, et cela ne nécessite en aucune manière la normalisation de tous ces services (ni l’interdiction que les entités fournissant les services aient aussi des données personnelles).

Sans oublier que ne pas avoir d’ID unique n’empêche en rien des actions légales envers les personnes si nécessaire, bien au contraire, exemple :

https://iiscn.wordpress.com/2011/06/17/un-exemple-dutilisation-des-m-accounts-reparer-lemail/

Principes du Maccount (aide mémoire)

Relationnel vers « fonctionnel » (aide mémoire)

En résumé :

• Le modèle dit relationnel est une machine à créer des doublons sur les atomes « attributs fonctions », et le terme « foreign_key » un symptôme de bêtise
• Le modèle fonctionnel proposé correspond à considérer une base comme un ensemble de fonctions définies par extension (et non compréhension), c’est à dire que les graphes de ces fonctions sont définis par extension
• Il faut en fait 4 ou 5 « function images table » : 1 pour les fonctions à un argument, 1 pour les fonctions à 2 arguments, 1 pour les fonctions à 3 arguments, etc
• Mais ceci n’est pas gênant, en terme de fonctions définies par extension, jamais beaucoup d’arguments, et d’autre part un argument peu aussi être une liste ou un array
• Le « modèle » objet  n’est que diverses conventions plus ou moins semblables sur applicabilité des entités « attributs fonctions » aux divers atomes

Note : rien de vraiment nouveau ci-dessus

Tpædia

Concept :

Tpædia, short for « technical encyclopedia »,  « transversal encyclopedia », or something like that, is meant to be a wiki using ISCNs as native entry keys.

The objective isn’t to make it complete in anyway, but more to use it as the focal documentation point for the ISCN initiative projects.

Concepts, projects, existing codes will be added according to on going needs.

Eventually it should also be implemented in TiNLisp, or in other words be an interface to the TiNlisp world.

Initial focus to be on Unicode objects/concepts and related.

Les espaces dits « hiérarchiques » ne le sont pas, la plupart du temps

Draft :

• a1.a2.a3 peut être considéré comme :
1. les valeurs de a2 doivent être uniques dans le contexte a1 (vision ou compréhension hiérarchique)
2. a1.a2.a3 est une phrase ou s-expression, donc la valeur a2 (le symbole a2 dans ce cas) dans a1.a2.a3 est la même que dans a1.a3.a2 ou a1.a2.a3.a2
• La « bêtise » ou erreur du RH name tree avec les numéros parallèles aux mots clés (quand l’intérêt des numéros est dans la mise à plat permettant éventuellement de changer les mots clés, comme les inodes dans un file system par exemple permettent de changer les noms de fichiers, ou le fait que si plusieurs livres sont vendus dans un coffret, le coffret en tant que produit a lui-même un ISBN,  —à côté— des ISBNs des livres qui le compose)
• Retournement de perspective : vision « top level », dans le cas 1), versus distributeur d’étiquettes ou symboles uniques, dans le cas 2)
• Séparations typologiques ou organisationnelles
• Quand on croit utiliser des espaces comme 1), on les utilise en fait de fait souvent comme 2), typiquement dans les conventions UNIX (/lib, /doc, fichiers « README »), mais pas uniquement
• Vision erronée du besoin d’identifiant des organisation pour chaque espace typologique (cf la RFC 3402 par exemple dans l’exemple industrie automobile)
• Avec les ISCNs, une même source peut-être utilisée dans n’importe quel contexte typologique, donc pas besoin de demander un préfixe ou segement par contexte typologique pour une organisation donnée.
• Une organisation acquière des sources, puis les utilisent dans n’importe quel contexte typologique
• l’aspect hiérarchique dans ce cas est donc là pour les besoins de distribution et non de classification, classification vient toujours après à travers d’autres ISCNs
• même si « globalement », les espaces d’identifiants se mettent en place dans un contexte toujours plus ou moins typologique avant d’être organisationnel

Autre :

• critique de l’emploi du terme « ressource » dans URN ou URL, ou « object » dans DOI (texte de Berners-Lee à ce sujet si l’on veut)
• critique du besoin perçu d’ « actionability », dans les LSID, Ark, ou DOI
• le besoin d’identification est indépendant de ces aspects d' »actionability », qui reviennent de toute manière à associer une certaine sémantique à un segment ou second identifiant
• Quand on a besoin d’identifier des trucs on utilise des ISCNs, sans se poser de question
• NT-maps et NT-spaces

Liens :

RFC3402 : http://www.ietf.org/rfc/rfc3402.txt

Concepts économie numérique draft

Il y a :

• Des utilisateurs
• Des « M account managers »
• Des Service providers, content diffusers, hosters
• Des Shops
• Des éditeurs et créateurs d’œuvres, de services, (sites, films, disques, sites genres static contents ou pas)
• Utilisation des ISCNs pour toutes les problématiques d’identification (et donc en particulier de tous les numéros GS1, ISBN,  ISAN ou autres, pour beaucoup d’œuvres existantes quand ça fait sens)

D’autre part :

• Chaque utilisateur a un (ou quelques) M-account
• Chaque M-account est « géré », à un instant donné, par une organisation « M account manager »
• Un M account peut être transféré d’un M account manager à un autre
• Le M account number est utilisé dans aucune transaction
• Un utilisateur peut acheter des œuvres ou éditions dans n’importe quel shop, sous forme de licence « à vie » ou d’abonnement
• Une œuvre ou édition d’oeuvre ou service est à un instant donné hosté par un hoster (cela peut changer)
• Les accounts managers peuvent être les banques?, FAIs?, ou nouvelles organisations ?, mais en tout cas plusieurs et licence de rôle spécifique

Note : modèle également présenté dans copies_licenses (nov 2007)

Et même organisations et comptes « nécessaires »(enfin utilisable) pour la problématique « net identity » (où l’approche ID unique par utilisateur partagé entre tous les services n’est en rien nécessaire, et devrait être évitée à tout prix)

 

Concept de structure de site books-blog-wiki

• Le site est une liste de livres
• Livres sur trois ou deux colonnes en page d’accueil, blocs réguliers
• Aperçu de la table des matières dans chaque bloc, ou « pitch » du livre (à la manière anciennes tables des matières, genre Rabelais ou Voltaire)
• Colonne de droite liste de tous les updates (avec filtres éventuels sur les genres d’updates (nouveaux chapitres/section, simple modif, etc)
• cliquer sur un livre amène à une page « lecture d’un livre », avec TOC à gauche, et séparation en page web rusée en fonction de la TOC
• En édition, on est en file system ou database jusqu’au niveau de la section (ou configurable), sinon en simple markup (markmin ou ReST), cela permet toute réorganisation des sections facilement
• La colonne de droite fournit le côté blog, temporel, flux des nouveautés
• Le markup fournit une macro « define » permettant d’allouer des nouveaux ISCNs et de définir des nouveaux concepts/objets, accessible en tant que tels dans le wiki, également macro « display def »
• Sans doute besoin d’un genre de fichier « .o » pour chaque section, histoire de ne pas bousiller ISCNs déjà alloués à chaque édition.
• wiki et index même chose ? A séparer ?

ISCN.com et site

Projet :

Organisation privée ayant pour objectif de développer divers projets autour des ISCNs.

Le site de cette organisation contient en particulier :

• La gestion des projets associés
• Un wiki du genre « what is ? » pour n’importe quel ISCN
• Il est écrit sous forme « liste de livres », ou bibliothèque
• D’offrir une gestion des sources (et préfixes)  en SAAS, non obligatoire bien sûr, mise à part le premier segment dont la gestion est sous la responsabilité de ISNC.org

Le fait de séparer cette organisation d’ISCN.org a pour objectif de garder ISCN.org aussi petite que possible, et la gestion du premier segment aussi facilement transférable que possible.

ISCN.org website

Projet :

Le site web de l’organisation ISCN.org , à priori à developper en utilisant web2py en première version au moins.