People and Skills - Schema and example change proposal

This proposal only concerns the person data example of the standard. It does not touch the badge part of the standard.

I will discuss the badge part in a different proposal.

Background

I downloaded the PSS example along with the schema from https://standards.internetofproduction.org/pub/r7g0n9fo/release/4

I proceeded to validate the example against the schema, but the validation failed.

On examination it turns out that:

• The example does not contain all required fields
• The example contains fields not in the schema

Schema

My opinion is that the schema contains too many required fields.

I propose to relax the constraints, making only the bare minimum of them required.

As this JSON schema does not disallow fields not present in the schema, means there is less need to be explicit about the requirements.

I propose this relaxed version of the schema:

{
  "title": "Maker Passport: Record Creation",
  "type": "object",
  "required": [
    "dateGenerated",
    "UUID",
    "lastName",
    "firstName",
    "preferredFirstName",
    "nationality",
    "residenceCountry"
  ],
"properties": {
    "dateCreated": {
      "type": "string",
      "title": "Today's Date",
      "description": "Date this user record was created in the system.",
      "format": "datetime",
      "options": {
        "flatpickr": {}
      }
    },
    "UUID": {
      "type": "string",
      "title": "Record Number",
      "description": "UUID generator: https://www.uuidgenerator.net",
      "minLength": 4,
      "default": ""
    },
    "lastName": {
      "type": "string",
      "title": "Last Name",
      "description": "User's surname.",
      "minLength": 4,
      "default": ""
    },
    "firstName": {
      "type": "string",
      "title": "First Name",
      "description": "User's given name.",
      "minLength": 4,
      "default": ""
    },
    "middleName": {
      "type": "string",
      "title": "Middle Name",
      "description": "User's middle name (if any).",
      "minLength": 4,
      "default": ""
    },
  "preferredFirstName": {
      "type": "string",
      "title": "Preferred Name",
      "description": "What the user prefers to be called when addressed.",
      "minLength": 4,
      "default": ""
    },
    "email": {
      "type": "string",
      "title": "Email Address",
      "description": "The user's email address.",
      "pattern": "^\\S+@\\S+\\.\\S+$",
      "format": "email",
      "minLength": 6,
      "maxLength": 127,
      "default": ""
    },
    "phone": {
      "type": "string",
      "title": "Phone Number (Home)",
      "description": "User's home phone number.",
      "minLength": 10,
      "maxLength": 20,
      "pattern": "^(\\([0-9]{3}\\))?[0-9]{3}-[0-9]{4}$",
      "default": ""
    },
    "mobilePhone": {
      "type": "string",
      "title": "Phone Number (Mobile)",
      "description": "The user's mobile phone number.",
      "minLength": 10,
      "maxLength": 20,
      "pattern": "^(\\([0-9]{3}\\))?[0-9]{3}-[0-9]{4}$",
      "default": ""
    },
    "dateOfBirth": {
      "type": "string",
      "title": "Date of Birth (DOB)",
      "description": "Date user was born; ask for confirmation of DOB with a government-issued ID card, if available, especially since confirmation of age may impact access to spaces, equipment, or services.",
      "format": "date",
      "options": {
        "flatpickr": {}
      }
    },
    "nationality": {
      "type": "array",
      "title": "Countries of Citizenship",
      "minLength": 1,
      "items": {
    "type": "string",
        "description": "Use the ISO 3166 standard for country name: https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes. If there are more than one country of citizenship, separate using a comma."
      }
    },
  "city": {
      "type": "string",
      "title": "Current City of Residence",
      "description": "If there are multiple cities, list the one where the user lives most of the time.",
      "minLength": 4,
      "default": ""
    },
    "identity": {
    "type": "array",
    "title": "Objects defining ways of identifying the subject",
    "items": {
      "type": "object",
      "description": "May be zero-knowledge digests of ID document images, public keys, etc...",
      "default": []
    }
    }
}
}

And the (validated) example becomes:

{
    "firstName" : "Sarah",
    "preferredFirstName": "Sarah",
    "lastName": "Hutton",
    "email" : "sarah@iopa.org",
    "dateGenerated": "2023-03-27T12:34:56.000Z",
    "UUID": "ba52c94f-a9c3-4e55-a103-1bc46b1608df",
    "state": "0xabcdef0123456789abcdef0123456789abcdef00",
    "nationality": ["US"],
    "residenceCountry": "US",
    "identity": []
}

See sections below for comments on these changes

Comms

There should be no need to require phone nor email. Some may use either (i.e. at least anyOf constraint is needed). Some may prefer not to disclose. And I think in very near future we will see more use neither.

Key

It should be possible for the subject to provide one or more public keys as future proof of their identity (and custody).

Nationality

Some may have multiple nationalities. The schema should allow for that.

Please avoid political colonialism

I also strongly contest the inclusion of the "preferredPronouns" field. This is because it has strong colonial undertones, in suggesting that everyone using this standard by implication have to accept this as a political issue, and on terms dictated by its origin in "western" political doctrine.

It should suffice that the schema allows any field extranous to the schema to be present. And simple "Duck Typing" can be applied by those limiting their interest to the strict schema.

Migration

I further propose to define this JSON schema as a downstream format, and appoint an RDF standard instead.

My belief is that this project would come out much stronger by following these two strategies:

• Allowing and encouraging communities and groups of communities to devise and use their own vocabularies to describe the contents and features of their activities.
• Making a system that on most levels can be reasonably validated by humans and machines alike.

In my view, RDF is designed specifically for these purposes.

Not only does it allow any kind of mash-up of taxonomies and vocabularies, but its data members can all be URLs, which easily lets a human follow the link and learn and verify the details and intent behind the data member (like contents of a course etc).

Or, since the data members are all, in fact, URIs, unambiguously define members in a content addressed fashion (e.g. URN:sha256:<hash>) to make sure any signatures over it renders later change of data impossible.

Example

Below is an example of how the example of the current PSS standard could be expressed in rdf instead.

I use the turtle RDF format for readability:

@prefix pss: <http://internetofproduction.org/rdf/pss/current#>
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix dct:    <http://purl.org/dc/terms/> .
@prefix sha256: <URN:sha256:> .
@prefix uuid: <URN:uuid:> .
@prefix wot:    <http://xmlns.com/wot/0.1/>.
@prefix iso3316a2:  <https://www.iso.org/obp/ui/#iso:code:3166:> .


uuid:80aecb88-04c7-4587-92c1-e3ac9f24d992
    wot:fingerprint "C0036D11C5386757A45242B471AB077CA401983F" ;
    a   wot:pubKey .


uuid:ba52c94f-a9c3-4e55-a103-1bc46b1608df
    dct:created "2023-03-27T12:34:56+00:00"^^xsd:dateTime ;
    foaf:GivenName  "Sarah" ;
    foaf:FamilyName "Hutton" ;
    foaf:name   "Sarah Hutton" ;
    pss:nationality iso3316a2:US ;
    pss:residenceCountry    iso3316a2:US ;
    wot:hasKey  uuid:80aecb88-04c7-4587-92c1-e3ac9f24d992 ;
    a   pss:Person .

# pss:Person must be wot:User and foaf:Agent