The following proposal for updates to the PSS schema is submitted by Louis Holbrook for review and feedback. Please review the proposed changes and provide your feedback by Tue Aug 20, after which it will be integrated into v4 for the next release.
- Accept Proposed Changes As-Is
- Accept Proposed Changes with Amendments (please list as reply in thread)
- Reject Proposed Changes (please list reasoning as reply in thread)
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
