A Database Per Entity on the Planet - A Deeper Dive on SOLICT

December 27, 2023 update - I strongly suggest readers skim “How Do I Trust Entities??? Different Levels of Identity & Credential Assurance - A Thought Paper”

April 18, 2024 Update - I edited the doc to include SOLICTs for AI systems and bots. Make sure you skim the end section on security architecture.

The prior article introduced an out of the box idea - give each person on the planet their own database containing their source of legal identity and credential truth (SOLICT). This articled begins to dive deeper into the weeds, containing my thoughts on components, questions, etc. It's NOT a quick read, as there's much to chat about.

This article is aimed at legal, database, identity, security, network architects, etc.

This article used the term "ENTITY" to indicate the actual entity whom the SOLICT data is about. It also uses the term "MANAGER" for an entity who is legally delegated to manage a ENTITY' SOLICT data, e.g. a parent/legal guardian, owner of a bot, et.c

Components

• Authoritative legal credential sources
• Toda
• SOLICT database per entity
• Consent
• Authentication
• Authorization
• Session Assurance
• Special cases
• Legal agreements
• Global standards
• Global, independent, non-profit
• PIAM (personal identity access management) to manage consent,?legal agreements and access management
• Token server?
• Updating SOLICT system
• Archival & data recovery policies
• Security architecture

Authoritative Legal Credential Sources

Issue's legal identity, credentials, changes to them. Examples include:

• Rethought CRVS (civil registration vital statistics) system which also obtains forensic biometrics, e.g. fingerprints and iris
• School/post-secondary credentials
• Health credentials, e.g. Covid vaccinations
• Has a verifiable digital signature approved by the global, independent, non-profit
• Exports legal identity/credentials to SOLICT using global standards via Toda

Reference link: Skim the SOLICT section in "Cost Centre - Rethinking Legal Identity & Learning Vision". Also skim “TODA, EMS, Graphs – New Enterprise Architectural Tools For a New Age”.

Authoritative Legal Credential Sources - Relationships

Legal identity MUST be able to show legal identity relationships between different legal parties. Examples include:

• Parent/child
• Legal guardian/child
• Marriage partners
• Power of attorney/person
• Executor of estate/deceased identity
• Owner of a bot/bot
• etc.

This will be done by the authoritative source cryptographically cross-linking different people's SOLICT data. So Jane Doe and her son John Doe's SOLICT data would be cryptographically cross-linked to each other showing a parent/child relationship. This is the tool to establish a PERSON/MANAGER LEGAL RELATIONSHIP

Reference link: Skim Legal Identity & Hive Relationship section in "Cost Centre - Rethinking Legal Identity & Learning Vision"

Authoritative Legal Credential Sources – Authorization Rights

Authorization rights for managing consent per database attribute will be done via export TODA capability files (i.e. I'm not sure of the actual database architecture for this). For example the local authority would write a capability file to Jane and John Doe's SOLICT giving Jane control over managing John's legal identity and credentials.

• These will be set by the global, independent non-profit

The entity might have the capability of delegating some of their authorization rights to others. Hypothetically, Jane Doe might delegate some of her management rights of John Doe, to her parents for 3 weeks while she's away. This allows his grandparents the ability to control what identity data is released when he's in an AI/AR/VR environment at their place, as well as being able to legally prove his identity if he's taken to a hospital.

HOWEVER, note this becomes a slippery slope. I can easily see criminals leveraging this to obtain control over a person say in the sex trade. Thus, very careful thought must be given to this before implementation.

Capability files will be to global standards. I feel the capability files will be widely adopted because it's now out of each enterprise's control, i.e. they'll need it to determine what to do with consent from each person regarding their legal identity, data and credential use.

Who will be the standards body for the capability files? The non-profit is a likely fit.

Authoritative Legal Credential Sources – What’s Not Included

Actual micro data about an entity – Examples include:

• Education data, e.g. Digital Learning Twin (DLT)
• Health data
• These may be contained within the person’s citizen identity vault and/or distributed

TODA

• Used by authoritative source to securely, send legal identity/credential information to the SOLICT, and for the SOLICT to send to the LSSI devices
• Able to prove the data was sent (hash of the file) on a certain data and time to the SOLICT or LSSI endpoint without duplication to other databases
• Used by PERSON/MANAGER of SOLICT to agree to consents to use data within SOLICT
• Potential used by third parties to provide their consent to SOLICT in conjunction with Kantara's UMA - hypothetically, leveraging Toda with UMA makes some sense since TODA can prove the consent was sent from the third party to SOLICT on a certain data and time - this needs to be fleshed out and either adopted or not

Reference Link: '“TODA, EMS, Graphs – New Enterprise Architectural Tools For a New Age”.

SOLICT

• Database per entity
• Stored in a global cloud outside a jurisdiction’s control
• SOLICT IS NOT OWNED BY THE ENTITY i.e. it’s the legal identity and credential source for an entity's identity?
• HOWEVER, An entity is the manager of their SOLICT data
• Mostly, the entity is in control of their SOLICT data
• Exceptions to this include children, people requiring power of attorney, etc.
• Edge use cases need to be created defining exceptions -this is potentially a slippery slope as malicious people might want to use these to control a entity's legal identity and credentials

SOLICT - What's Not Included

Micro databases, e.g.

• Health
• Education
• Etc.
• I feel these are potential mine fields politically, commercially, etc.
• The person may or may not control these, e.g. they may delegate their rights to others willingly, or out of ignorance

?My thoughts - keep the scope tight for SOLICT and don’t try to solve the planet’s data privacy problems

SOLICT Database Design

• The SOLICT will likely have "hive relationships" within them, sent via the CRVS
• These will be one to one, one to many, and many to many
• They may change VERY fast (to see what's coming over the next several years skim “Nanobots, Microbots, Manufacturing, Risk, Legal Identity & Contracts”)

Assumptions:

• The data can only be written and never deleted
• Database can never be deleted
• Only archived
• Ability for a jurisdiction to change attributes
• How will the changes be noted?
• Use cases need to be created for “edge cases”, e.g. fake identity, malicious jurisdiction trying to alter an attribute about a person, etc.

SOLICT Database Architecture Policies

• Authentication policy for authoritative source to write to the database
• Authorization policies for the following:
• Authoritative source
• Consent manager
• Third parties consuming the information agreed to by the consent manager
• Others?
• Archival/storage policies
• Legal contracts/policies (see legal section)
• Others?

SOLICT - Security

• See last section of this article

SOLICT - Legal Agreements

• This is the most important component piece
• Need LOTS of legal expertise/help here understanding the scope of this, as well as driving out the details/deliverables, etc., i.e. there will likely be lots of detail for this
• The legal contracts spell out the function and policies of SOLICT
• IT MUST BE ABLE TO LEGALLY FUNCTION PAN-JURISDICTIONS AROUND THE PLANET
• It will likely leverage AI leveraged smart contracts

Consent

There are five forms of consent:

• Authoritative source who’s writing the data to SOLICT
• Third party wanting to access a piece of data within SOLICT
• “ENTITY” who SOLICT is about
• “MANAGER” of SOLICT on behalf of “ENTITY”
• Legal ruling requiring access to SOLICT data

Consent - Authoritative Source

• What consent mechanism(s) need to be in place for an authoritative source to write to SOLICT?
• How will this actually work?
• Use cases need to be developed
• It should start off with the CRVS creating SOLICT from birth
• All consents, and any writing to the database, MUST be recorded within SOLICT
• Other?

Consent - Third Party Accessing SOLICT Data

• The actual consent mechanism should likely be some form of Kantara User Managed Access (UMA) - this may or may not be required to be modified
• A dumb question: If say Acme Inc. is granted access to Jane Doe’s legal identity name, what needs to be included in the consent from Jane/SOLICT manager to Acme regarding Acme’s authentication/authorization rights to then query the database and obtain her legal identity name?
• How will this actually occur?
• Other?

Consent - "ENTITY" Who SOLICT is About

• Assumption: Assuming the person is of legal age, then they won’t require consent to access their SOLICT data to view it
• Is this assumption correct or not?
• See authorization section for more questions of viewing data
• Any time ”ENTITY” accesses SOLICT, their access MUST be recorded in the consent file within SOLICT i.e. its self-consent - is this assumption correct or not?
• How will the “ENTITY'S” PIAM play in all of this? - see PIAM section of this article
• Other?

Consent – “MANAGER” of SOLICT on Behalf of “ENTITY”

• Assumption: MANAGER won’t require consent to access their SOLICT data to view it - is this assumption correct or not?
• See authorization section for more questions of viewing data
• Any time ”MANAGER” accesses SOLICT, their access MUST be recorded in the consent file within SOLICT i.e. its self-consent - is this assumption correct or not?
• How will the “MANAGER'S” PIAM play in all of this? - see PIAM section of this article
• Other?

Consent – Legal Ruling Requiring Access to SOLICT Data

• Use cases MUST be created addressing this
• This is the edge of a potentially very slippery slope as malicious states and criminals will likely try to use this to access “ENTITY's” data
• Assuming these use cases are valid, then what type of legal consent is required to then access ”ENTITY's” data, how should it be recorded in the consent file and how is this consent used to then authenticate and authorize the court to obtain the data they have specified?
• Other?

Authentication

There are five entity types requiring authentication:

• Authoritative source who’s writing the data to SOLICT
• Third party wanting to access a piece of data within SOLICT
• "ENTITY” who SOLICT is about
• “MANAGER” of SOLICT on behalf of “ENTITY”
• Legal ruling requiring access to SOLICT data

Authentication - Authoritative Source

• What is the credential assurance level required for the authoritative source’s system to authenticate to SOLICT?
• Will there be different credential assurance levels required for different types of authoritative sources based on risk? - e.g. a CRVS writing a legal identity might have a different risk level than say a high school writing a graduation credential to SOLICT
• All authentication events should be recorded somewhere in the SOLICT database

Authentication – Third Party Accessing SOLICT Data

• Based on the dumb question asked in consent, if say Acme Inc. is granted access to Jane Doe’s legal identity name, what needs to be included in the consent from Jane/SOLICT “Manager” to Acme regarding Acme’s authentication rights to then query the database and obtain her legal identity name?
• How will this actually occur?
• Will there be different levels of credential assurance for different types of access to SOLICT? - e.g. A request to prove Jane’s a human is potentially at a different credential risk level that if they want to obtain her forensic biometrics
• All authentication events should be recorded somewhere in the SOLICT database
• Other?

Authentication – “ENTITY” Who SOLICT is About

• What type of credential assurance should be used for “ENTITY”?
• Should there be stronger credential assurance for accessing different portions of SOLICT by “ENTITY”? - e.g. If Jane wants to view all her consents given from birth to date, is the risk higher or not than viewing her school credentials?
• All authentication events should be recorded somewhere in the SOLICT database
• How will the “ENTITY's” PIAM play in all of this? - see PIAM section of this article
• Other?

Authentication – “MANAGER” of SOLICT on Behalf of “ENTITY”

• What type of credential assurance should be used for “MANAGER”?
• Should there be stronger credential assurance for accessing different portions of SOLICT by “MANAGER”? - e.g. If Manager wants to view all?consents given for Jane from birth to date, is the risk higher or not than viewing her school credentials?
• All authentication events should be recorded somewhere in the SOLICT database
• How will the “MANAGER’s” PIAM play in all of this? - See PIAM section of this article
• Other?

Authentication – Court Requiring Access to SOLICT Data

• How will the consent be used to then authenticate the court’s system or their appointee to obtain the data they have specified?
• As per the above types of entities, are their different credential assurance levels required to access different portions of ”ENTITY's” SOLICT?
• All authentication events should be recorded somewhere in the SOLICT
• Other?

Authorization

There are five entity types requiring authorization:

• Authoritative source who’s writing the data to SOLICT
• Third party wanting to access a piece of data within SOLICT
• “ENTITY” who SOLICT is about
• “Manager” of SOLICT on behalf of “ENTITY”
• Legal ruling requiring access to SOLICT data

Authorization - Authoritative Source

• What is the authorization policy required for the authoritative source’s system to authorize to SOLICT?
• All authorization events should be recorded somewhere in SOLICT database
• Other?

Authorization – Third Party Accessing SOLICT Data

• Based on the dumb question asked in consent, if say Acme Inc. is granted access to Jane Doe’s legal identity name, what needs to be included in the consent from Jane/SOLICT “Manager” to Acme regarding Acme’s authorization rights to then query the database and obtain her legal identity name?
• How will this actually occur?
• All authorization events should be recorded somewhere in SOLICT database
• Other?

Authorization – “ENTITY” Who SOLICT is About

• What type of authorization policies should be used for “ENTITY”?
• All authorization events should be recorded somewhere in SOLICT database
• How will the ”PERSON” PIAM play in all of this? - see PIAM section of this article
• Other?

Authorization – “MANAGER” of SOLICT on behalf of “PERSON”

• What type of authorization policies should be used for “MANAGER”?
• All authorization events should be recorded somewhere in SOLICT database
• How will the “MANAGER’s” PIAM play in all of this? - see PIAM section of this article
• Other?

Authorization – Court Requiring Access to SOLICT data

• How will the consent be used to then authorize the court’s system or their appointee to obtain the data they have specified?
• All authorization events should be recorded somewhere in SOLICT database
• Other?

Session Assurance

Based on the answers to the credential and authorization policies already asked then, during a session, the credential and/or identity risks might require increased stronger levels of identity and/or credential assurance

Special Cases

• There are always exceptions in life requiring special cases
• Examples include leaders of countries, spies, people being sheltered by a government, .e. witness relocation program, etc.
• These are edge cases which also are the beginning of a slippery slope for criminals/malicious states will try to leverage these to do potentially bad things
• Use cases MUST be created and then very careful thought given to them
• If you make an exception once, it can be reused over and over as justification for other people/entities

Standards

Without standards, SOLICT won’t be able to exist and function around the planet. SOLICT will likely use or create the following global standards. Examples include:

• New CRVS data standards for legal identity
• Kantara User Managed Access (UMA)
• TODA
• Capability authorization files
• Legal consent contracts
• etc.

Standards - Global Bodies

• Wherever possible, SOLICT should leverage existing standards bodies - e.g. Health, professional bodies, etc.
• HOWEVER, the global standards bodies must be prepared to rapidly adjust them based on new attack vectors created by this curve https://hvl.net/pdf/PatScannellHockeyStickShapedCurve.pdf
• As the global, independent, non-profit identifies very high risk attack vectors affecting the global standards, their transmission to SOLICT, etc. then the global bodies MUST be prepared to readily change standards, business processes, etc. as per the threat levels
• That's where the new, global, independent, well-funded non-profit comes into play

Global, Independent, Well-Funded Non-Profit

• It’s the gatekeeper for both Toda LSSI and SOLICT
• Thus, at an operational level, it’s the most important operational piece

It oversees:

• Standards
• 24x7x365 threat analysis against legal identity/credential governance, business processes, tech and end users
• Security and fixes
• It manages the politics associated with Toda LSSI and SOLICT
• Since it’s planetary, relying upon each jurisdiction to comply, this is also one of the main critical components of SOLICT

Global, Independent Non-Profit Suggested Scope

• Oversees coordination of global standards bodies responsible for legal identity and credential standards
• Coordination means the following:
• Inserting themselves into the change management lifecycle for applicable standards such that any potential change affecting SOLICT is notified and well tested out in advance
• Inserting themselves into emergency change processes
• This will likely be created by the non-profit identifying very high risks for a specific standard requiring emergency fix processes
• The goal is to have a seamless process for both the responsible standards body and the non-profit re SOLICT

It might or might not be responsible for the following standards:

• CRVS legal identity
• PIAM (Personal identity access management)

Other scope activities:

• Does 24x7x365 threat analysis against the legal identity and credentials used in SOLICT and a PERSON’s Toda LSSI
• Produces threat analysis
• Monitors changes made as a result of the threat analysis and fix recommendations implemented
• Oversees implementation of standards and fixes to Toda LSSI and SOLICT databases
• Other?

Global Independent Non-Profit Governance

Very careful thought need to be taken when considering who governs the non-profit. I suggest a mix of the following:

• Some global standards bodies
• A representative from legal law societies
• A representative from a privacy body
• Other?

I also suggest voting require 2/3 majority to make a major change on the board. This prevents rapid changes in board management.

Finally, I also suggest a group of independent auditors be required to independently audit the non-profit to ensure it’s “squeaky clean”.

Global Independent Non-Profit Funding

• Governments pay a fee for use of the new age CRVS system plus also enabling LSSI up to a maximum amount per year
• Addressing this is one of the most important components of the SOLICT puzzle
• If the amount of money raised is too small, it will result in the non-profit cutting corners,?and likely lead to weak overall security, i.e. it could prove fatal to billions of SOLICT databases around the planet
• Other?

PIAM (Personal Identity Access Management) System

PIAM, leveraging AI will be used to conduct:

• Consent agreements/legal contracts on the fly between “ENTITY” or her “MANAGER” and third parties wanting to access “ENTITY'’s” SOLICT data
• Access management with the SOLICT and third parties
• Access management with “ENTITY” accessing their SOLICT
• Access management with “MANAGER” accessing “ENTITY’s” SOLICT

Some dumb questions about ENTITY/MANAGER’s PIAM and SOLICT:

• What role does the PIAM have regarding IAM management of SOLICT?
• What security and access monitoring systems are installed with ENTITY’s SOLICT?
• Does PIAM play a role in this?

PIAM requires standards to ensure all PIAM’s are securely, accessing and controlling access to PERSON’s SOLICT. I see the global, independent non-profit driving this, at least to start with.

Database Tokenization?

Dumb questions:

• Does the SOLICT database Token-ize it’s data? - This can mitigate risk of the SOLICT being hacked and the data being exposed
• How will this work with the potentially hundred of requests as “ENTITY” walks down a street, creating contracts on the fly, via ”ENTITY” PIAM, for releasing consent to various this parties? -Or, does it not work?
• If it does work, then the architecture must have a external facing database containing token data, with behind it the token server
• All of this needs to be very carefully thought out and architected for from a security perspective
• Other?

Skim these two articles:

• “An Identity Day in the Life of Jane Doe”
• “Smart Cities - Contracts, Privacy, Data & Legal Identities”

System Upgrades

Dumb questions:

• How will underlying system components be securely updated? - e.g. firewalls, endpoints, database, etc.
• How will this be automated?
• What will be hotfix update processes?
• Consider the scale in the not so distant future and reflect on implications, e.g. trillions of ENTITY’s SOLICT databases might require hotfix upgrades within hours
• Other?

Archival & Data Recovery Policies

• What happens to PERSON’s SOLICT when they die or are terminated?
• What conditions have to be required to archive a SOLICT database?
• What are the archival policies?
• What are retrieval policies if and when a SOLICT database has to be retrieved?
• All of this is VERY legal and must be well thought through
• As well, it’s also has costs, technical and security implications
• Other?

Security Architecture

All of the previous sections above affect the end-to-end security architecture for SOLICT, which is why I’ve put this at the end of the deck. I have some very serious security concerns relating to designing SOLICTs for AI systems and bots entities.

Performance:

I could see in my mind the awesome speeds at which say digital bots can be created. Over time, it could easily be in the millions or billions per second. Thus, I saw the CRVS local/global systems struggling not only with registration/validation performance, BUT ALSO CREATING A SOLICT FOR EACH NEW ENTITY.?Thus, this must be addressed in design use cases.

Security:

I could easily see how the Evil Inc.’s and malicious states of the planet would leverage this to create new types of denial-of-service attacks against the new age CRVS systems.?They could effectively “drown the CRVS” with creations of new entities and sending out to the global, independent non-profit, who’s managing the SOLICTS, LOTS of SOLICT creations. Thus, this must be addressed in design use cases.

Updating:

Finally, I could also see the business process problems of keeping track of trillions or more AI system and bots legal identities.?How would the CRVS be able to be notified an entity had changed, been adopted into another entity, terminated, etc. and then how would it notify the entity’s SOLICT??Thus, this must be addressed in design use cases.

?

My message??All of the above problems/challenges are whopper sized.?LOTS OF THOUGHT MUST BE APPLIED BEFORE DESIGN AND IMPLEMENTATION.

Security attack vectors include:

• Tech used
• Governance
• Business processes
• End user

All of the above MUST be fleshed out. It’s a moving target due to this curve - Thus, today’s best security architecture might be tomorrow’s turd.

SOLICT IS ALL ABOUT TRUST. So, the security architecture has to be “damned good” and continually “damned good”. As I see it, this is a very big challenge.

Summary

This article is my first attempt to think my way through the requirements to design, build, implement and maintain a SOLICT system. It’s out of the box thinking, which requires out of the box solutions. Thus, I welcome all comments, thoughts, criticisms and suggestions.

About Guy Huntington

I'm an identity trailblazing problem solver. My past clients include Boeing, Capital One and the Government of Alberta's Digital Citizen Identity & Authentication project. Many of my past projects were leading edge at the time in the identity/security space. I've spent the last eight years working my way through creating a new legal identity architecture and leveraging this to then rethink learning.

I've also done a lot in education as a volunteer over my lifetime.?This included chairing my school district's technology committee in the 90's - which resulted in wiring most of the schools with optic fiber, behind building a technology leveraged school, and past president of Skills Canada BC and Skills Canada.

I do short term consulting for Boards, C-suites and Governments, assisting them in readying themselves for the arrival of AI systems, bots and AI leveraged, smart digital identities of humans.

I've written LOTS about the change coming. Skim the?over 100 LinkedIn articles?I've written,?or my webpage?with lots of papers.

Quotes I REALLY LIKE!!!!!!:

• We cannot solve our problems with the same thinking we used when we created them” – Albert Einstein
• “Change is hard at first, messy in the middle and gorgeous at the end.” – Robin Sharma
• “Change is the law of life. And those who look only to the past or present are certain to miss the future” – John F. Kennedy

Reference Links:

An Identity Day in The Life:

• “An Identity Day in the Life of Jane Doe”

My Message To Government & Industry Leaders:

• “Why Should Your Government Fund The Architectures?”
• “National Security – Reduce Risk By Instantly Determining Entity Friend From Foe”
• “Give Your Industry A Significant Competitive Edge“
• "State/Provincial Leaders - A Major Problem Is Heading Your Way"
• “An Identity Day in the Life of Jane Doe”
• “Sir Ken Robinson - You Nailed It!” to understand how it will transform learning
• “National Security, Co-Design & People With Disabilities.”
• “Why Should You Read The 500 Page Cost Centre Document?
• “Budgetary Costs to Deploy a New Learning Architecture Leveraging a Rethought Legal Identity”

National Security:

• “National Security – Reduce Risk By Instantly Determining Entity Friend From Foe”
• “How Do I Trust Entities??? Different Levels of Identity & Credential Assurance - A Thought Paper”
• "Kids, National Security, Sex, Learning, Privacy, Disabilities & Laws"
• “National Security, Co-Design & People With Disabilities"
• “AI/Bots, National Security, Ethics, Privacy & Identity”
• "GOVERNANCE & TRUST"

Rethinking Legal Identity, Credentials & Learning:

• "Verifiable Credentials For Humans and AI Systems/Bots"
• "Why Disabled People Will Lead The Planet Rethinking Legal Identity, AI/Bots, Credentials & Learning"

• "My Learning Journey"

Learning Vision:

• “Vision: Learning Journey of Two Young Kids in a Remote Village”
• “Sir Ken Robinson - You Nailed It!”
• "Transformational Learning Vision”

Creativity:

• "Kids, Creativity, Learning & Sir Ken Robinson"

AI Agents:

• “Personal AI FinTech Agents - Risks, Security And Identity”
• “AI/Bots Health Agents, Medical IoT Devices, Risks, Privacy, Security And Legal Identity”
• “Marketing In The Age of AI Agents, Bots, Behavioural Tech and Crime”
• “Legal Departments - AI/Bots, Gen AI, AI Agents, Hives, Behavioural Tech And AI's Ability To Own LLC's”
• “AI Agents & Kids"
• “AI Agent Authorization - Identity, Graphs & Architecture”

Architecture:

• Humans - “Rethinking Human Legal Identity”
• AI Systems/Bots - “Creating AI Systems/Bots Legal Identity Framework”
• Learning - “Learning Vision Flyover”

AI/Human Legal Identity/Learning Cost References

• “AI/Human Legal Identity/Learning References”

• “Cost Centres – Rethinking Legal Identity & Learning Vision”
• Guesstimate Cost Notes Rethinking Legal Identity & Leveraging This to Rethink Learning?(Word Doc)
• Guesstimate Costs Rethinking Legal Identity & Leveraging This to Rethink Learning (Excel Spreadsheet)

AI Leveraged, Smart Digital Identities of Humans:

• “AI Leveraged Smart Digital Identities of Us”
• “DIGITAL IDENTITY...”
• Digital Twins/Virtual Selves, Identity, Security and Death – A Thought Paper”

CISO's:

• "CISO's-What's Your Security Strategy For AI, Bots, IoT Devices & AI Leveraged Smart Human Digital Identities?"
• "Enterprise Digital Change"

Companies, C-Suites and Boards:

• “Getting Your Company Ready for AI - What Boards and C-Suites Need to Know”

Legal Identity & TODA:

• “Legal Identity & TODA”

Enterprise Articles:

• “Legal Departments - AI/Bots, Gen AI, AI Agents, Hives, Behavioural Tech And AI's Ability To Own LLC's”
• “Marketing In The Age of AI Agents, Bots, Behavioural Tech and Crime”
• "Major Change – Future of HR"
• “AI/Bots Health Agents, Medical IoT Devices, Risks, Privacy, Security And Legal Identity”
• “TODA, EMS & Graphs – New Enterprise Architectural Tools For A New Age”
• "Entity Management System"
• "Personal AI FinTech Agents - Risks, Security And Identity"

Rethinking Enterprise Architecture In The Age of AI:

• “Part I AI Systems, Bots, AI Agents, IoT Devices, & Identity Architecture”
• “Part II Hives & Fast Changing Authorization Relationships”
• “Part III AI, Bots, Behaviour Tech & Security Models”
• “Part IV Enterprise Risk & Innovation Governance”

LLC's & AI:

• “Legal Identity Vs. Legal Personhood”
• “Toda and LLC Incorporation”

Challenges With AI:

• “The Challenge with AI & Bots - Determining Friend From Foe”
• AI Systems/Bots Beginnings & Endings - A Whopper Sized Problem”
• “Hives, AI, Bots & Humans - Another Whopper Sized Problem”
• “AI Leveraged Smart Digital Identities of Us”
• "Deep Fakes, Privacy, Protection & Misinformation"
• “Decentralized AI – Risks, Legal Identity, Consent & Privacy"
• "Give Every AI a Soul - or Else"
• “How Do I Trust Entities??? Different Levels of Identity & Credential Assurance - A Thought Paper”

New Security Model:

• "Zero Trust On Steroids - Rethinking Security Models For Citizens And Enterprises In The Age of AI Agents And Tech"

DAO:

• "DAO - Identity, Members & AI Systems/Bots"

Kids:

• “Kids & Digital Identities”
• "Kids & Digital Identity Wallets"

Sex:

• “Kids, Sex, Metaverses & Privacy”
• “Sex & Identity”

Schools:

• “The Coming Classroom Revolution – Privacy & Internet of Things In A Classroom”
• “Kids, Digital Learning Twins, Neural Biometrics, Their Data, Privacy & Liabilities”?
• “Bots, Classrooms, Privacy, Legal Identity & Contracts”
• “We Have An Identity Problem – AI/Bots in School, Home & Work”
• “Kids, Schools, AI/AR/VR, Legal Identities, Contracts and Privacy”
• “EdTech Law – Legal Identity Contracts”
• “AI, Cheating & Future of Schools/Work”
• “Using AI/Digital Learning Twins in Assessment & Education”

Biometrics:

• “I Hate How We Use Biometrics Today”

Legal Identity:

• “Revised Laws of Identity”
• "Legal Identity Problem Statements"
• “Legal Identity & TODA”

• "Digital Identity & Legal Identity Relationships - IT'S A PROBLEM"
• “Legal Person: Humans, Clones, Virtual and Physical AI Robotics – New Privacy Principles”

Identity, Death, Laws & Processes:

• “Death & Digital Identity”
• “Kids, Death & Digital Identities”
• “Digital Death & Metaverses”

Open Source:

• "Open Source & Legal Identity"

Notaries:

• “Notaries, Digital Identities & New Age”

Climate Change, Migration & Legal Identity:

"Human Migration, Physical and Digital Legal Identity - A Thought Paper”

Fraud/Crime:

• "Synthetic Identity Fraud, Kids, AI and Smart Digital Identities"
• Argentina’s National ID Database Hacked
• Newfoundland’s Health Database Hacked

Behavioral Marketing:

• “I Know Who You Are & What You’re Feeling – Achieving Privacy in a Non-Private World”
• “Privacy Gone – AI, AR, VR, Robotics & Personal Data”

AI Systems and Bots:

• “AI, Bots & Us - Examples of Rapid Change”
• “Decentralized AI – Risks, Legal Identity, Consent & Privacy”
• "ChatGPT, AI, Identity & Privacy"
• “Why We Need To Legally Register AI Systems and Bots”
• “Why AI Regulation Requires Legal Identities of AI Systems and Bots”
• “Artificial Intelligence & Legal Identification – A Thought Paper”
• “Mission Control – We Have a Problem”
• “Lease or Rent a Bot! Rapidly Emerging Contract Law & Legal Identity Challenges”
• “The Infrastructure Behind Coordinating up to 3,000 bots in One Factory”
• “Nanobots & Legal Identity”
• “Micro Flying Bots & Legal Identity”
• “Microbots Able to Swim Through Your Body & Legal Identity”
• “Bots, Swarms, Risk & Legal Identity”
• “Nanobots, Microbots, Manufacturing, Risk, Legal Identity & Contracts”

Contract Law:

• “A Rapidly Growing Problem – Contract Law & Legal Identities”

Insurance:

• “Insurers Need a New Legal Toolkit”
• “Digital Identities, Risk, Insurance & Death”

Health:

• “Covid, Health & Legal Identity – Leading from the Heart”
• “Digital Health Record & Legal Identity”
• “Health & Bots – A Personal Story”

AI/AR/VR Metaverse Type Environments:

• “Metaverse Bots?”
• “Lifelike Avatars, Risk & Legal Identity”
• “Metaverse, Identity, Data, Privacy, Consent & Security”
• “Challenges With Metaverse Contracts”

SOLICT:

• “Give Each Person Their Own Source of Legal Identity & Credential Truth Database (SOLICT)”
• “A Database Per Person on the Planet - A Deeper Dive on SOLICT”
• “Please Pass This Along to Database Thinkers”

EMP/HEMP Data Centre Protection:

• “When Our Digital Legal Identity Trust Goes Poof!”
• “US Moves Towards Plan Addressing GMD and HEMP Events”
• “The Threat to Digitization”

Climate:

• "Sometimes I Want to Cry - Why?"

A 100,000-Foot Level Summary Of Legal Human Identity

• Each person when they’re born has their legal identity data plus their forensic biometrics (fingerprints, and later when they can keep their eyes open – their iris) entered into a new age CRVS system (Civil Registration Vital Statistics - birth, name/gender change, marriage/divorce and death registry) with data standards
• The CRVS writes to an external database, per single person, the identity data plus their forensic biometrics called a SOLICT “Source of Legal Identity & Credential Truth).?The person now controls this
• As well, the CRVS also writes to the SOLICT legal identity relationships e.g. child/parent, cryptographically linking the SOLICTs.?So Jane Doe and her son John will have cryptographic digitally signed links showing their parent/child.?The same methodology can be used for power of attorney/person, executor of estate/deceased, etc.
• The SOLICT in turn then pushes out the information to four different types of LSSI Devices “Legal Self-Sovereign Identity”; physical ID card, digital legal identity app, biometrically tied physical wristband containing identity information or a chip inserted into each person
• The person is now able, with their consent, to release legal identity information about themselves.?This ranges from being able to legally, anonymously prove they’re a human (and not a bot), above or below age of consent, Covid vaccinated, etc.?It also means they can, at their discretion, release portions of their identity like gender, first name, legal name, address, etc.
• NOTE: All consents granted by the person are stored in their SOLICT
• Consent management for each person will be managed by their PIAM “Personal Identity Access Management) system.?This is AI leveraged, allowing the person, at their discretion, to automatically create consent legal agreements on the fly
• It works both locally and globally, physically and digitally anywhere on the planet
• AI systems/bots are also registered, where risk requires it, in the new age CRVS system
• Governance and continual threat assessment, is done by a new, global, independent, non-profit funded by a very small charge per CRVS event to a jurisdiction to a maximum yearly amount.

A 100,000-Foot Level Summary Of The Learning Vision:

• When the learner is a toddler, with their parents’ consent, they’ll be assessed by a physical bot for their learning abilities.?This will include sight, sound, hearing and smell, as well as hand-eye coordination, how they work or don’t work with others, learning abilities, all leveraging biometric and behavioral data
• All consents given on behalf of the learner or, later in the learner’s life by the learner themselves, are stored in the learner’s SOLICT “Source of Legal Identity & Credential Truth”
• This is fed into a DLT “Digital Learning Twin”, which is created and legally bound to the learner
• The DLT the produces its first IEP “Individualized Education Plan”, for the learner
• The parents take home with them a learning assistant bot to assist the learner, each day, in learning.?The bot updates the DLT, which in turn continually refines the learner’s IEP
• All learning data from the learner is stored in their LDV “Learner Data Vault”
• When the learner’s first day of school comes, the parents prove the learner and their identities and legal relationship with the learner, via their LSSI devices (Legal Self-Sovereign Identity)
• With their consent, they approve how the learner’s identity information will be used not only within the school, but also in AI/AR/VR learning environments
• As well, the parents give their consent for the learner’s DLT, IEP and learning assistant bot to be used, via their PIAM (Personal Identity Access Management) and the learner’s PIAM
• The schools LMS “Learning Management System” instantly takes the legal consent agreements, plus the learner’s identity and learning information, and integrates this with the school’s learning systems
• From the first day, each learner is delivered a customized learning program, continually updated by both human and AI system/bot learning specialists, as well as sensors, learning assessments, etc.
• All learner data collected in the school, is stored in the learner’s LDV
• If the learner enters any AI/AR/VR type learning environment, consent agreements are created instantly on the fly with the learner, school, school districts, learning specialists, etc.?
• These specify how the learner will be identified, learning data use, storage, deletion, etc.
• When the learner acquires learning credentials, these are digitally signed by the authoritative learning authority, and written to the learner’s SOLICT.
• The SOLICT in turn pushes these out to the learner’s LSSI devices
• The learner is now in control of their learning credentials
• When the learner graduates, they’ll be able, with their consent, to offer use of their DLT, IEP and LDV to employers, post-secondary, etc.?This significantly reduces time and costs to train or help the learner learn
• The learner continually leverages their DLT/IEP/LDV until their die i.e., it’s a lifelong learning system
• IT’S TRANSFORMATIONAL OVER TIME, NOT OVERNIGHT