The Internet of Production Alliance People and Skills Specification (PSS) BETA Release

License: Creative Commons Attribution 4.0 International License (CC-BY 4.0)

Contents

1. Introduction: provides a broad overview of the background, scope and aim of this standard.

2. Scope: provides information on the specification audience, application, and overarching authorisation workflow.

3. Jargon Buster: provides definitions to key terms used through the specification document.

4. Specification for People and Skills Mutual Recognition: provides the metadata schema for PSS, including fieldname(s), purpose, rules, and examples.

5. Governance of this Specification: provides guidance on how the PSS will be developed and maintained.

6. References: List of citations for resources used during development of the PSS beta release.

1. Introduction

Emerging technology is already transforming the way we produce goods, services, and experiences, allowing more people to join in the design and fabrication process. To build a sustainable system that is globally networked and locally executed, a combination of open infrastructure, information, processes, and data specifications needs to be developed and shared openly with the global community. Providing makers, makerspaces, SME and start-ups with resources and access to networks and open standards and tools, makes rapid collaboration, new revenue streams, and sustainable business models more achievable for entrepreneurial stakeholders in a global manufacturing ecosystem.

The Internet of Production Alliance (IoPA) is working to establish five families of open infrastructure that enable anyone, everywhere, to participate in production.

Currently, this work is centered around five families of digital infrastructure which cover the essential ingredients needed to make anything:

1. Designs & Documentation (Open Know-How/OKH)

2. Machines & Tools (Open Know-Where/OKW)

3. People & Skills - currently under development; BETA released

4. Materials & Components - research and scoping underway

5. Contracts & Business Models - research and scoping underway

Initiatives emerge and are driven by collective community interest in the exploration of common focus areas, either within one or across multiple infrastructure families. The IoPA is currently working with community stakeholders on continued development of the first two of the five families listed below.

1.1. Designs & Documentation: Open Know-How (OKH)

The goal of this data specification is to provide a mechanism for exchanging know-how for making things, in alignment with the Open Source Hardware Definition [1]. This is done so by providing a schema for providing metadata in a consistent format and a mode of information exchange enabling indexing and discovery of open hardware projects by stakeholders.  With the understanding that know-how can be tacit, the OKH data specification is concerned with know-how represented in documentation, drawings, digital models, source code and other media. Community discussion and support of continued development of OKH is supported by engagement platforms provided by the IoPA, which include contributions from global stakeholders on updates to the specification, potential use cases, and general knowledge sharing related to OKH.

1.2. Machines & Tools: Open Know-Where (OKW)

The goal of the OKW data specification is to provide a mechanism for the discovery and exchange of the location of manufacturing capabilities and where to get something made. The aim is to develop the enabling technologies and infrastructures in support of a global move to distributed and local manufacturing, by providing a schema for quick and simple documentation of manufacturing capabilities, manufacturing facilities, machinery, and tooling. Community discussion and support of continued development of OKH is supported by engagement platforms provided by the IoPA, which include contributions from global stakeholders on updates to the specification, potential use cases, and general knowledge sharing related to OKW.

1.3. Introducing the People and Skills Specification (PSS): BETA

The central focus of the People and Skills Specification (PSS) is to create a shared understanding of the explicit, implicit, tacit, and procedural knowledge necessary for individuals to make things. This specification is also intentionally designed to provide a framework for sharing those skills and experiences with potential employers, fellow makers, and educational institutions via the Open Badge System Framework [3]; this specification can also be used as a stand-alone, should an open badging system not be an option.

Building on OKH and OKW, which address how we share knowledge for making things, and where things can be made, the PSS addresses the third critical component of knowledge-sharing for the reproducability of items - who can provide the expertise for making things. This is done with a focus on the experience and skills necessary for production, and how those skills and experiences can be shared. By establishing a shared understanding and vocabulary surrounding the production of goods, we have the potential to open up networked conversations between experts in digital and physical fabrication.

PSS provides the potential for broadening a global network of experts, helping place the possibility of product prototyping into the hands of community members, which means increased potential for rapid collaboration, and increased overall quality of the products being produced. Increased recognition of expertise and awareness of who has this expertise also means that products being made are manufactured with fresh community knowledge and skill, which means better products for our society. The increasingly diverse engineering talent that will now have the potential to recognize local, specialized knowledge, will appeal to industry and larger manufacturing companies, which supports individual makers seeking industry jobs.

1.4. Research and Community Scoping for the Beta Release

The PSS beta release is based on an emergent framework as defined in grounded theory (GT) methodology, which is an inductive paradigm that provides a foundation for targeted information gathering [2]. Assertions and the framework for the PSS beta standard have been derived from the following research and community scoping activities (listed chronologically by order of execution):

• Extensive desk research, including document analysis and literature review, the results of which were used to establish questions for community interviews;

• 25 semi-structured interviews with global maker community members, focusing on passport program developers/leads, the analysis of which informed targeted survey questions;

• 96 survey responses from global maker community members, focusing on makerspace leaders and targeted questions regarding nomadic maker practices, preferences, and the utility of a maker passport.

1.5. Beta Release and Subsequent Versioning

The People and Skills specification has been developed by building upon existing badging initiatives and educational and mutual recognition accords. Extensive research and community scoping has been conducted, leading to the preliminary authoring of a PSS beta release.

Following the beta release of PSS, a working group is being convened to collaboratively co-author the next version. Working Group members:

Collaborative review and technical authoring will continue with a v1.0 projected release date of June 15, 2023.

2. Scope

This specification provides a mechanism for verification within mutual recognition and microcredentialing systems for purposes of:

1. Identifying WHAT expertise is needed

2. Confirming WHO has the expertise

3. HOW this expertise is communicated

While the PSS provides potential for some of the capabilities listed below now, the broader PSS Initiative provides the infrastructure for reaching some of the farther-reaching goals listed below:

1. Identifying WHAT expertise is needed: this specification provides standardized, yet flexible, categories of skills and experience which can be mapped to specific types of making and project work, allowing for a shared understanding of what a certain type of training or experience means across organizations, consortia, or other larger networks. For example, production spaces have varying rules for providing access to use their spaces for production, based on what machinery, materials, or chemicals are in the space. With this specification, an organization can customize requirements for different levels of access.

2. Confirming WHO has the expertise: this specification supports the creation of a user record for the individual maker, that can easily be integrated into preexisting systems that catalog or track organization membership rosters, whether connected to a public, private, or academic institution. The structure of this user record is also designed with data sovereignty in mind; an individual maker will be able to take their user record, download it, and take it with them - it does not have to be attached to any organization that “owns” it.

3. HOW this expertise is communicated: this specification is created with the flexibility to serve as a stand-alone form or, using the provided tooling, could be used to fill out an online form that exports a JSON file that can be integrated into an open badging system. This allows for:

   1. A makerspace to create a form tailored to their organizational needs to keep local records of users who have been credentialed to access certain spaces and/or specialized equipment;

   2. An educational institution to establish a microcredentialing (using open badges) system to communicate which workshops, classes, or other skills-based training has successfully been completed by an individual;

   3. An individual to have the capability to communicate their credentials to a potential employer, via professional or social media platforms, or as a stand-alone file export.

While this specification is designed to be interoperable with common open badging standard protocols, it can also be used without internet connectivity to maintain paper records in-house using the provided template in section 4.10, for makerspaces that either do not have the infrastructure to support an open badging system, or require manual record load for maintaining local records.

2.1. Use Cases and Ongoing R&D

2.1.2. Immediate Use Case: Navigating a Pan-African Ecosystem

By design, the PSS could be adopted and adapted by anyone who wishes to have a credentialing system which enables nomadic makers to travel between makerspaces, such as that being developed as a part of the mAkE project. This navigation will be enabled by using a digital 'maker passport,' the preliminary criteria for which has been defined by maker community members during the research process preceding the PSS BETA release. You can read more about this project, sponsored by the European Horizon 2020 Programme here: https://makeafricaeu.org/about.

2.1.3. Ongoing R&D

IoP initiatives emerge and are driven by collective community interest in the exploration of common focus areas, either within one or across multiple infrastructure families. The PSS Initiative, in addition to providing the infrastructure for reaching some of the farther-reaching goals for PSS, also provides many avenues for contributing to the iterative improvement of the specification, as well as the development of tooling in support of implementing at the local level:

• PSS Initiative Charter

• PSS: Development Priorities

• PSS: General Inquiries

2.2 Maker Authorization and Credentialing Workflow

Based on preliminary research and community scoping, a workflow for a maker passport has been developed:

Adapted from Open Badges 2.0 workflow [9]

This system is reliant on two main points of verification:

1. Passport holder (maker) identity

2. Passport holder (maker) credentials

2.3. Maker Identity

The identity of passport holders can be established via organizational affiliations, or preexisting verification processes (OpenID, OAuth2, etc.).

2.4. Maker Credentials

What a maker needs to prove they know and what experiences they need to provide proof of prior to being allowed entree into a makerspace within the ecosystem.

3. Jargon Buster

Terms and definitions used throughout the specification.

3.1 Displayers:

Website or web application that provides tools for displaying PSS credentials.

3.2 Earner:

User/resources owner who earns a credential from an issuer.

3.3 IdP (identity provider):

Performs authentication and passes the user's identity and authorization level to the service provider.

3.4 Issuer:

Organization, guild, or individual that grants credentials to a user in the form of a digital badge or other format.

3.5 IssueInstant:

Timestamp to indicate the time a new identification number/ID was generated.

3.6 LTI:

Learning Tools Interoperability

3.7 OAuth (open authorization):

An open standard for access delegation, commonly used as a way for internet users to grant websites or applications access to their information on other websites but without giving them the passwords.

3.8 OpenID Connect:

Built on the OAuth 2.0 protocol and uses an additional JSON Web Token (JWT), called an ID token, to standardize areas that OAuth 2.0 leaves up to choice, such as scopes and endpoint discovery. It is specifically focused on user authentication and is widely used to enable user logins on consumer websites and mobile apps.

3.9 SP (service provider):

Trusts the identity provider and authorizes the given user to access the requested resource. Associated with EntityID (unique identifier)

3.10 User:

An individual maker who may be issued a maker passport or learning credential.

4. Specification for People and Skills Mutual Recognition

4.1 Introduction

This section specifies a mechanism for the verification of passport holders (makers) by authorised issuers. Building on foundational schemas in open badge system frameworks [3], this specification provides the conceptual framework for mutual recognition within a functional badging system; it does not provide a schema for the functional badging system itself, though multiple open badging systems are referenced.

Any infrastructure designed and developed to support an open digital badging system should support [3, p10]:

4.1.1. Independent-Source Badge Issue

Similar to assessment design and execution, badges can be issued by authorities, course organizers, peers, the system or each learner. Within the open badge infrastructure, it is important to allow for badges from many independent sources across the Web and across each learner's experience to ensure that the badge system supports all of their learning.

4.1.2. Badge Collection

Badges should be collected in a way that ties them to the learner identity and enables use across websites or experiences. Learners can get badges from many environments or experiences, through many different types of assessments, and store them in a single badge collection as they go. Each badge should carry comprehensive metadata to communicate information about the issuance of the badge, provide a link back to the learner’s work as demonstration and justification of the badge and enable authentication back to the issuer. The learner should also have an interface to their badge collection to manage badges and set privacy controls.

4.1.3. Badge Display

The value of badges increases further when learners have control over where to display them across audiences and contexts. The learner should be able to control which badges are available for which audience and share subsets of badges with selected audiences, ranging from target groups or networks, to the open web. Further, the infrastructure should allow learners to add badges to any external website or environment that supports badge display, including personal websites, such as blogs, and social networking environments such as LinkedIn or Facebook. Finally, these display sites should be able to authenticate the badge to ensure that the badge was issued to this particular user.

This specification provides recommendations for display platforms based on community scoping research; for application of this specification within an open badging infrastructure contextualized for a specific use case, additional user research must be conducted to ensure that the selections for badge display are in alignment with user community needs. The power of credentialing resides in not only the authorising entity, but also the interoperability of the issued credential with platforms that are relevant and meaningful to the earner.

Mandatory and recommended provisions are made along with other fields that are defined. A template is provided that can be used to aid in the development of a digital maker passport, or could be used to input data manually, for makers and organisations that are not yet a part of a digital network or digital recognition system.

4.2 Method of Information Exchange: The PSS User Record

The PSS User Record accompanies the officially and unofficially credentialed skills and experiences that are documented in structured or unstructured formats. The purpose is to allow automated indexings of key properties about the user and to identify and link to the associated issuing clients.

The user record shall be used to define user record changes over time.

The user record should be updated when any credential status or user descriptor data changes.

4.3 Structure of the Output as a File

4.3.1. Format

Where the user record is contained in a file, it will be JSON [4].

Note: JSON is selected because not only is it a structured data format, but it can also be used directly in client-side coding. It is for this reason that JSON is the predominant format for digital badging systems.

JSON requires Unicode [5]; while UTF-16 may also be used for character encoding, the UTF-8 [6] default is recommended [7].

4.3.2 Filename

The file containing the user record shall begin with “pss”.

The file extension shall be “.json”.

Example: “pss.json”

The user’s name may be included in the filename, prefixed with a hyphen.

Example: “pss-user-name.json”

4.4. Displaying Output Information on a Web Page

JSON format is the predominant format used to store data in a structured way. JSON data can easily be displayed in an HTML page using JavaScript in the form of tables and lists [8].

Example: HTML Table with data retrieved as JSON

const dbParam = JSON.stringify({table:"customers",limit:20});
const xmlhttp = new XMLHttpRequest();
xmlhttp.onload = function() {
   myObj = JSON.parse(this.responseText);
   let text = "<table border='1'>"
   for (let x in myObj) {
     text += "<tr><td>" + myObj[x].name + "</td></tr>";
   }
   text += "</table>"
   document.getElementById("demo").innerHTML = text;
}
xmlhttp.open("POST", "json_demo_html_table.php");
xmlhttp.setRequestHeader("Content-type", "application/x-www-form-
urlencoded");
xmlhttp.send("x=" + dbParam);

4.5. Output Metadata

4.5.1. User Record Unique Identifier

Fieldname: id

Purpose: Assignment of a unique identifier will make user records easier to locate, also allowing for easier differentiation between versions.

Format: UUID [9]

"id" : "a3cdb71f-d1c8-4867-90af-d7dd6c6391a8"

Rules: Required.

4.5.2. Date User Record Created

Fieldname: date_created

Purpose: Identifies date user record was originally created.

Format: YYYY-MM-DD [10]

"date_created" : "2022-09-27 18:00:00.000"

Rules: Required.

4.5.3. Date User Record Last Updated

Fieldname: last_updated_date

Purpose: Identifies date user record was last updated.

Format: YYYY-MM-DD

"last_updated_date" : "2022-09-27 18:00:00.00Rules: Required.

4.5.4. Record Issuer

Fieldname: record_issuer

Purpose: Identifies the entity issuing the passport.

Format: Object.

Rules: Required.

4.5.4.1. Name of organization issuing maker passport

Fieldname: name

Purpose: Identifies the entity issuing the passport.

Format: Text.

Rules: Required.

4.5.4.2. Primary contact at issuing organization

Fieldname: primary_contact

Purpose: Identifies the primary contact at the entity issuing the passport.

Format: Object.

Rules: Recommended.

4.5.4.2.1. Primary contact name

Fieldname: name

Purpose: Provide the email of the primary contact at the entity issuing the passport.

Format: Text.

Rules: Subfields required if object is present.

4.5.4.2.2. Primary contact email

Fieldname: email

Purpose: Provides the email of the primary contact at the entity issuing the passport.

Format: Text.

Rules: Subfields required if object is present.

Example record_issuer and primary_contact objects

"record_issuer" : {
  "name" : "IOPA",
  "primary_contact": {
    "name" : "Sarah Hutton",
    "email" : "[email protected]"
  }
}

4.6. User Properties

Fieldname: user

Purpose: Contains user metadata.

Format: Object.

Rules: Required.

4.6.1. User Name

Fieldname: name

Purpose: States the first name (forename) and last name (surname) of the user to which the passport is issued.

Format: Text; last name, first name.

Rules: Required.

4.6.2. User Email

Fieldname: email

Purpose: Email address of the passport holder.

Format: Text; [email protected]

Rules: Required.

4.6.3. User Authentication

Fieldname: openid_token

Purpose: Authentication via OpenID Connect [11] provides a way to prove that an end user controls an Identifier. It does this without the Relying Party needing access to end user credentials such as a password or to other sensitive information such as an email address. OpenID Connect performs similarly to OpenID 2.0 [12], but does so in a way that is API-friendly, and integrates OAuth 2.0 capabilities directly into the protocol.

Format: OpenID Connect Token URL

${baseURL}/v1/token

Rules: Required. Recommended apps for provision of OAuth token: GitHub, Facebook, Twitter, Google.

4.6.4. User Affiliations

To identify related consortia, organizations, guilds, and other networks which can lend to validation of experience and skills held by user.

Fieldname: affiliations

Purpose: To identify any consortia, organizations, guilds, and other networks which can lend to validation of experience and skills held by user.

Format: Text.

Rules: Recommended; if affiliations provide a badge issuance token and/or API badge identifier, enter badge tokens in 4.7.1. Certifications.

4.6.5. User Photo

Fieldname: image

Purpose: For visual identification of user when entering a space within the maker ecosystem.

Format: URL

Rules: Recommended.

Example of User Properties Object

"user" : {
    "name" : "Sarah Hutton"
    "email" : "[email protected]"
    "openid_token" : "token",
    "affiliations" : [
        {
          "name" : "IOPA"
          "primary_contact" : {
            "name" : "Andrew Lamb"
            "email" : "[email protected]"
          }
        },
        {
          "name" : "OSHWA"
        }
    ],
    "image" : "https://iopa.org/about/sarah.png"
}

4.7. Certification Properties

Those with digital badges that are compliant with the Open Badge specification [13] that are authorized/signatory compliant in alignment with

4.7.1. Certifications

Fieldname: certifications

Purpose: Serves as a container for all issued certifications, badges, skills training evidence.

Format: Array.

Rules: Required.

4.7.2 Digital Badges

Purpose: Identifies digital badges earned by passport holder.

Format: Object.

Rules: Required if entering badges. If Open Badge-compliant badges have not been earned by user, this field is not applicable.

4.7.2.1. Badge name

Fieldname: badge_name

Purpose: Identifies earned digital badge by name.

Format: Text.

Rules: Required if entering badges. If Open Badge-compliant badges have not been earned by user, this field is not applicable.

4.7.2.2. Badge criteria

Fieldname: badge_criteria

Purpose: Typically located in the description section of an open badge, this information describes what knowledge has been gained/skills have been proven for earner to receive badge.

Format: Text.

Rules: Required if entering in badges. If Open Badge-compliant badges have not been earned by user, this field is not applicable.

4.7.2.3. Badge URL

Fieldname: badge_url

Purpose: Location/hosting site of earned badge.

Format: URL

4.7.2.4. Issue date

Fieldname: badge_issue_date

Purpose: Date badge was issued to earner.

Format: YYYY-MM-DD

Rules: Required if entering in badges. If Open Badge-compliant badges have not been earned by user, this field is not applicable.

4.7.2.5. Issuer

Fieldname: issuer

Purpose: Location/hosting site of earned badge.

Format: Object

Rules: Required if entering in badges. If Open Badge-compliant badges have not been earned by user, this field is not applicable.

4.7.2.6. Recipient

Fieldname: badge_recipient

Purpose: Identifies the user who earned the badge.

Format: Object; see 4.6 User Properties

Rules: Required if entering in badges. If Open Badge-compliant badges have not been earned by user, this field is not applicable.

"certifications" : [
  {
    "badge_name" : "health and safety badge",
    "badge_criteria" : "health and safety training, badge in first aid",
    "badge_url" : "https://badges/io/hasbadge",
    "badge_issue_date" : "2023-02-14",
    "issuer" : {
      "name" : "OpenBadgeHaus",
      "primary_contact" : {
        "name" : "Bill Badger",
        "email" : "[email protected]"
      }
    },
    "badge_recipient" : {
      "name" : "Sarah Hutton",
      "email" : "[email protected]"
  }}
]

4.7.2.7. Alignment (with specific standards/accrediting bodies)

Fieldname: badge_alignment

Purpose: Identifies related standards with which alignment is pertinent/meaningful to the passport issuer (need to pick a new work for passport issuer!).

Format: Text.

Rules: Recommended if entering in badges. If Open Badge-compliant badges have not been earned by user, this field is not applicable.

4.7.2.8. Additional information about the Issuer

Fieldname: issuer_additional_info

Purpose: Provides additional information about the organization that issued the badge, such as authorized issuer platform status [28].

Format: Text.

Rules: Recommended if entering in badges. If Open Badge-compliant badges have not been earned by user, this field is not applicable.

4.7.2.9. Expiration Date

Fieldname: expiration_date

Purpose: Identifies the expiration date of the badge as identified by issuer.

Format: YYYY-MM-DD

Rules: Recommended if entering in badges. If Open Badge-compliant badges have not been earned by user, this field is not applicable.

4.7.2.10. Badge Evidence

Fieldname: evidence

Purpose: In the case that a badge token or URL is not available for proof of issuance, this field is used to gather information that could serve as supporting evidence that the badge has been earned by the user affiliated with it.

Format: Text.

Rules: Required if entering in badges. If Open Badge-compliant badges have not been earned by user, this field is not applicable.

4.7.2.11. Revocation/Revocation Reason

Fieldname: revocation

Purpose: Identifies when a badge has been revoked and for what reason.

Format: Text.

Rules: Recommended if entering in badges. If Open Badge-compliant badges have not been earned by user, this field is not applicable.

4.7.2.12. Tags

Fieldname: badge_tags

Purpose:

Format: Array.

Rules: Required if entering in badges. If Open Badge-compliant badges have not been earned by user, this field is not applicable.

"certifications" : [
  {
    "badge_name" : "health and safety badge",
    "badge_criteria" : "health and safety training, badge in first aid",
    "badge_url" : "https://badges/io/hasbadge",
    "badge_issue_date" : "2023-02-14",
    "issuer" : {
      "name" : "OpenBadgeHaus",
      "primary_contact" : {
        "name" : "Bill Badger",
        "email" : "[email protected]"
      }
    },
    "badge_recipient" : {
      "name" : "Sarah Hutton",
      "email" : "[email protected]"
    },
    "badge_alignment" : "https://badges.io/hasbadge/alignment",
    "expiration_date" : "2024-12-31",
    "issuer_additional_info": "Also issues paper certificates",
    "badge_tags": ["health", "safety"]
  }
]

4.9 Language and Translation

Language shall be declared as defined in BCP 47 [14], which prescribes the format for identifying languages as the ISO 639 [15] codes for representing languages followed by the ISO 3166 [16] code for the region in which the language is used. Use the Alpha-2 code for each where available.

4.10 User Record Template

ETA April 2023

%PSS user record 0.1

5. Governance of This Specification

Changes will be discussed with community members and voted on during meetings of the People and Skills Working Group. 

Proposers should consult the Working Group prior to proposing changes so that members can contribute to the development of proposals.

All proposed changes will be shared on the community forum for review prior to Working Group meeting discussions. This can increase the likelihood of the group accepting changes to the specification.

6. References

[1] Open Source Definition, Open Source Hardware Association, https://www.oshwa.org/definition

[2] Socio-Technical Grounded Theory for Software Engineering, Hoda, R (2022), 10.1109/TSE.2021.3106280

[3] An Open Badge System Framework, Peer 2 Peer University & The Mozilla Foundation, in collaboration with The MacArthur Foundation, http://bit.ly/badgepaper4

[4] JSON Data Interchange Syntax Standard, ECMA International, https://www.ecma-international.org/publications-and-standards/standards/ecma-404/

[5] The Unicode® Standard 15.0.0, https://www.unicode.org/versions/Unicode15.0.0/

[6] UTF-8 encoding table and Unicode characters, https://www.utf8-chartable.de/

[7] Choosing and applying a character encoding, W3C, https://www.w3.org/International/questions/qa-choosing-encodings

[8] JSON HTML, W3C School, https://www.w3schools.com/js/js_json_html.asp

[9] RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace, https://www.rfc-editor.org/rfc/rfc4122

[10] ISO 8601: Time and Date Format Standard, https://www.iso.org/iso-8601-date-and-time-format.html

[11] OpenID Connect 1.0 Specification, https://openid.net/connect/

[12] OpenID Authentication 2.0 - Final, https://openid.net/specs/openid-authentication-2_0.html

[13] 1EdTech/openbadges-specification, https://github.com/1EdTech/openbadges-specification

[14] BCP 47 Tags for Identifying Languages, IETF, https://tools.ietf.org/html/bcp47

[15] Codes for the Representation of Names of Languages, Library of Congress, http://www.loc.gov/standards/iso639-2/php/code_list.php

[16] Country Codes – ISO 3166, ISO, https://www.iso.org/iso-3166-country-codes.html