Universal Badge Specification (UB-SPEC) v0.1.0

### Incomplete Working Draft Proposal 12 July 2023 | More details about this document | | | --- | --- | | This version | link | | Latest published version | link | | Latest editor's draft | link | | History | link, Commit history | | Editors | Adam Eunson, Merul Dhiman | | Authors | Adam Eunson, Merul Dhiman | | Feedback | Repo Link (Pull Requests, New Issue, Open Issues) | | Related documents | link | ###### © Tangle Labs UG (Eunson, Dhiman). Tangle Labs UG liability and trademark terms apply. --- # Abstract The Universal Badge Specification (UB-SPEC) is a technical specification developed to offer a consistent and interoperable framework for the representation of non-formal and formal learning credentials, as verifiable digital badges. Built upon the W3C Verifiable Credential Data Model, the UB-SPEC defines a structured data model, as well as guidelines for the creation, issuance, management, and verification of interoperable digital badges, that can be issued to digital identities represented by decentralised identifiers (DIDs), using self-sovereign identity (SSI) best practices. Through the adoption of the UB-SPEC, organisations and individuals can ensure the portability and authenticity of digital badges, allowing for a more inclusive and verifiable ecosystem for the recognition of achievements, experiences, and competencies. # Status of this document This document is experimental and is undergoing heavy development. It is inadvisable to implement the specification in its current form. This is a draft document and may be updated, replaced, or determined obsolete at any time. It is inappropriate to cite this document as anything other than "work in progress." Feedback and contributions from the community are welcome and encouraged. > **Due to the experimental draft status of this document it is not recommended for live implementation.** --- # Introduction *This section is non-normative.* The Universal Badge Specification (UB-SPEC) defines a collection of standardised data models, guidelines, and best practices for the creation, issuance, management, and verification of digital badges for the representation of non-formal and formal learning credentials. This specification builds upon the W3C Verifiable Credential Data Model recommendaiton, aiming to provide a universal and interoperable solution for the representation and validation of achievements, skills, and competencies. The specification aims to address the following goals: - **Interoperability** Foster interoperability and compatibility among diverse badge issuers and verifiers by providing a common data model, vocabulary, and schema for representing and exchanging badge-related information. - **Trust and Verifiability** Enhance the trustworthiness and verifiability of digital badges through the utilization of cryptographic techniques, such as digital signatures, verifiable credentials (VCs), and decentralized identifiers (DIDs), ensuring the integrity, authenticity, and non-repudiation of badge data. - **Flexibility and Extensibility** Allow for flexibility in defining badge types and their associated criteria, enabling badge issuers to tailor the specifications to their specific domains and requirements. The specification also allows for future extensions and enhancements to accommodate evolving needs and emerging technologies. - **Privacy and User Control** Promote privacy and user control by providing guidelines for the secure storage, transmission, and sharing of badge-related data. Individuals should have control over the visibility and disclosure of their badge information while adhering to applicable privacy regulations. By establishing a standardized approach to digital badges, the Universal Badge Specification aims to streamline badge issuance and verification processes, enable seamless integration with existing systems, and enhance the portability, trustworthiness, and value of digital badges across various sectors including education, workforce development, vocational certification, and more. ## Overview of Universal Badges *This section is non-normative.* A universal badge is a collection of claims made by an issuer, represented by a Decentralised Identifier (DID) about a credential subject, also represented by a DID. These claims are issued as a Verifiable Credential (VC). This credential is cryptographically signed by the issuer to a credential holder, also represented by a DID, and may then be presented or shared by the holder to verifiers. The UB-SPEC outlines the recommended practices for data models and schema, as well as additional recommendations for the presentation, disclosure, storage, and sharing of badges, to support an interoperable universal badge ecosystem, based upon self-sovereign identity (SSI) best practices. The UB-SPEC aims to address the need for an open-source, standardised approach to the representation and exchange of non-formal educational, vocational, and skills-based credentials and micro-credentials in the form of digital badges leveraging the W3C Verifiable Credentials Data Model specification and W3C DID-CORE specification to provide a general-purpose framework for creating and verifying tamper-evident digital credentials through self-sovereign identity. > By leveraging these foundation standards, the UB-SPEC ensures compatibility and interoperability with any future verifiable credential and DID based ecosystem. ## What are verifiable credentials? *This section is non-normative - (extract from the W3C Verifiable Credentials Data Model standard)* In the physical world, a credential might consist of: - Information related to identifying the subject of the credential (for example, a photo, name, or identification number) - Information related to the issuing authority (for example, a city government, national agency, or certification body) - Information related to the type of credential this is (for example, a Dutch passport, an American driving license, or a health insurance card) - Information related to specific attributes or properties being asserted by the issuing authority about the subject (for example, nationality, the classes of vehicle entitled to drive, or date of birth) - Evidence related to how the credential was derived - Information related to constraints on the credential (for example, expiration date, or terms of use). A verifiable credential can represent all of the same information that a physical credential may represent. The addition of technologies, such as digital signatures, makes verifiable credentials more tamper-evident and more trustworthy than their physical counterparts. Holders of verifiable credentials can generate verifiable presentations and then share these verifiable presentations with verifiers to prove they possess verifiable credentials with certain characteristics. Both verifiable credentials and verifiable presentations can be transmitted rapidly, making them more convenient than their physical counterparts when trying to establish trust at a distance. The Verifiable Credential specification attempts to improve the ease of expressing digital credentials, it also attempts to balance this goal with a number of privacy-preserving goals. The persistence of digital information, and the ease with which disparate sources of digital data can be collected and correlated, comprise a privacy concern that the use of verifiable and easily machine-readable credentials threatens to make worse. The word "verifiable" in the terms verifiable credential and verifiable presentation refers to the characteristic of a credential or presentation as being able to be verified by a verifier, as defined in this document. Verifiability of a credential does not imply that the truth of claims encoded therein can be evaluated; however, the issuer can include values in the evidence property to help the verifier apply their business logic to determine whether the claims have sufficient veracity for their needs. ## Universal Badge Ecosystem *This section is non-normative.* This section explains the roles and relationships between the main participants within a universal badge ecosystem. Each role may be implemented in a number of different ways, and each role is not specifically exclusive, as one role may also act as another role within the ecosystem, for example, an issuer may also be a subject or holder. By separating roles, it allows us to define a clear overview for the standardisation of the specification. The following roles are used within a universal badge ecosystem: **Holder** A holder is an entity that stores a universal badge for the purpose of sharing it or creating a presentation to share with verifiers. The holder can be the subject of the badge or may also be a trusted data storage provider like a university, government, training provider, or custodial wallet provider. **Issuer** An issuer is an entity that acts as a provider of universal badges. They make claims about a credential subject and create, sign, and issue universal badges to holders. Issuers may be schools, employers, training centers, course tutors, or any other entity that wishes to issue universal badges. **Subject** A subject is the entity about which claims within a universal badge are made. This may be a student, organisation, employee, or any other entity. **Verifier** A verifier is an entity that wishes to validate claims made within a universal badge. Verifiers may be employers, educational institutions, governments, or any other entity that wishes to verify the authenticity of a universal badge. **Verifiable Data Registry** A verifiable data registry is a trusted repository used to securely store identifiers, keys, schemas, and other related information within a universal badge ecosystem. This may be a centralised server, decentralised storage system, blockchain, or any other trusted data management system. ## Universal Badge Lifecycle *This section is non-normative.* The lifecycle of a universal badge revolves around numerous interactions and information flows between the various roles within a universal badge ecosystem. The role participants and their interactions are as folows: - **Issuance** An issuer initiates the universal badge lifecycle by issuing a universal badge to a holder. This is the first action taken in relation to a universal badge and also may be referred to as the creation of a universal badge. - **Holder Transfer** A holder, once in possession of a universal badge, has the option to transfer one or more of their universal badges to another holder. This allows for the exchange of badges between individuals or entities. - **Holder Presentation** A holder can present one or more of their badges to a verifier. This may be done through directly sharing the entire universal badge, or inside a verifiable presentation, which provides additional verification mechanisms. - **Verifier Validation** A verifier plays a crucial role in the lifecycle by verifying the authenticity of the presented universal badge or the verifiable presentation containing the universal badge. This validation ensures the credibility and trustworthiness of the badge. - **Issuer Revocation** In certain circumstances, an issuer may decide to revoke a previously issued universal badge. This action invalidates the badge and removes its validity for future use. - **Holder Deletion** A holder also has the option to delete a universal badge from their records. This can be done when the badge is no longer needed or relevant. The primary interactions within the universal badge ecosystem support many possible use cases and examples. However, the most common scenario within the universal badge ecosystem is widely observed as: - An issuer issues a universal badge to a holder. - A holder presents the universal badge to a verifier. - A verifier performs the necessary verification steps to ensure the authenticity of the badge. ## Conformance As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. The key words *MAY, MUST, MUST NOT, RECOMMENDED, SHOULD,* and *SHOULD NOT* in this document are to be interpreted as described in [BCP 14](https://datatracker.ietf.org/doc/html/bcp14), [[RFC2119]](https://www.w3.org/TR/2023/WD-vc-data-model-2.0-20230617/#bib-rfc2119), [[RFC8174]](https://www.w3.org/TR/2023/WD-vc-data-model-2.0-20230617/#bib-rfc8174), when, and only when, they appear in itallic all capitals, as shown here. A conforming document is any concrete expression of the data model that complies with the normative statements in this specification. A conforming processor is any algorithm realised as software and/or hardware that generates or consumes a conforming document. Conforming processors *MUST* produce errors when non-conforming documents are consumed. This document also contains examples that contain JSON and JSON-LD content. Some of these examples contain characters that are invalid JSON, such as inline comments (//) and the use of ellipsis (...) to denote information that adds little value to the example. Implementers are cautioned to remove this content if they desire to use the information as valid JSON or JSON-LD. ## Disclaimer THIS WORK IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SOFTWARE OR DOCUMENT WILL NOT INFRINGE ANY THIRD-PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE SOFTWARE OR DOCUMENT. The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to the work without specific, written prior permission. Title to copyright in this work will at all times remain with copyright holders. This specification has been built upon the W3C Verifiable Credential Data Model specification. Excerpts and references have been included throughout this document and the respective copyright terms and rights to all W3C content apply. --- # Terminology *This section is non-normative.* The following terms are used to describe concepts within this specification. **badge** A type of verifiable credential containing claims about a credential subject that is cryptographically signed by an issuer, that adheres to the outlined universal badge specification. **baking** The process of embedding verifiable presentation metadata from a universal badge credential into an image file to create a "baked badge". **claim** An assertion made by an issuer about a credential subject. **credential** A collection of one or more claims made by an issuer about a credential subject. **credential subject** An entity about which claims within a universal badge are made. **decentralised identifier (DID)** A portable URL-based identifier, also known as a DID, associated with an entity. These identifiers are most often used in a verifiable credential and are associated with subjects such that a verifiable credential itself can be easily ported from one repository to another without the need to reissue the credential. An example of a DID is: `did:method:12345678901234567890`. **DID method** A definition of how a specific DID method scheme is implemented. A DID method is defined by a DID method specification, which specifies the precise operations by which DIDs and DID documents are created, resolved, updated, and deactivated. The method of a DID is visible in every DID. An example for the `DID:KEY` method is: `did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK` **entity** A thing with distinct and independent existence, such as a person, organisation, or device that may perform one or more roles within the universal badge ecosystem. **holder** A role an entity might perform by possessing one or more universal badges. A holder is usually, but not always, the subject of the universal badge they are holding. Holders store their universal badges in repositories. **issuer** A role an entity can perform by asserting claims about one or more subjects, creating a universal badge from these claims, and transmitting the universal badge to a holder. **presentation** Data derived from one or more universal badges, issued by one or more issuers, that is shared with a specific verifier. **proof** See verification and verification method. **repository** A program, such as a storage vault or digital wallet, that stores and protects access to a holders' universal badges. **selective disclosure** The ability of a holder to make decisions about what information contained within a universal badge they wish to disclose when presenting a universal badge to a verifier. **subject** See credential subject. **Uniform Resource Identifier (URI)** The standard identifier format for all resources on the World Wide Web as defined by [RFC3986]. A DID is a type of URI scheme. **Uniform Resource Locator (URL)** A URL, as defined by [RFC3986]. URLs can be dereferenced such that they result in a resource, such as a document or website. The rules for dereferencing or fetching an URL are defined by the URL scheme. **validation** The assurance that a universal badge or a verifiable presentation of a universal badge meets the needs of a verifier. This specification is constrained to verifying universal badges and verifiable presentations of universal badges. **verifiable credential** A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable credentials can be used to build verifiable presentations, which can also be cryptographically verified. All universal badges are verifiable credentials. **verifiable data registry** A role a system might perform by mediating the creation and verification of identifiers, keys, and other relevant data, such as universal badge schemas, revocation registries, trust registries, issuer public keys, and so on, which might be required to use universal badges. Some configurations might require correlatable identifiers for subjects. Some registries, such as ones for UUIDs and public keys, might just act as namespaces for identifiers. **verifiable presentation** A verifiable presentation is a tamper-evident presentation encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification. Certain types of verifiable presentations might contain data that is synthesised from, but does not contain, the original verifiable credentials (for example, selective disclosure). **verification** The evaluation of whether a verifiable credential or verifiable presentation is an authentic and timely statement of the issuer or presenter, respectively. This includes checking that: the credential (or presentation) conforms to the specification; the proof method is satisfied; and, if present, the status check succeeds. Verification of a credential does not imply evaluation of the truth of claims encoded in the credential. **verification method** A set of parameters that can be used together with a process to independently verify a proof. For example, a cryptographic public key can be used as a verification method with respect to a digital signature; in such usage, it verifies that the signer possessed the associated cryptographic private key. "Verification" and "proof" in this definition are intended to apply broadly. **verifier** A role an entity performs by receiving one or more universal badges, optionally inside a verifiable presentation for processing. Also known as a "relying party". --- # Universal Badge Key Concepts *This section is non-normative.* The UB-SPEC introduces several key concepts to enable the creation and verification of digital badges: ### Badge A badge represents a digital artifact that contains one or more claims about an entity. It serves as a verifiable and portable representation of an individual's accomplishments, digitally signed as a verifiable credential. - Badges are created, issued, and revoked by issuers. - Holders hold, present, transfer, and delete badges. - Verifiers verify badges. ### Badge Types A badge type represents a specific type of badge defined by an issuer. It includes a data model and schema defining the badge's name, description, image, issuer details, and other associated claims and criteria required to define the badge. ### Credential Subject A credential subject is the entity about which the credential makes claims. It can be an individual, a company, an organization, or any other relevant entity. ### Evidence Evidence refers to the activities, artifacts, or documents that substantiate a subject's claim for a badge. It can include transcripts, assessment results, coursework, presentations, or any other form of evidence defined by the issuer. ### Expiration Date An expiration date is the point at which a badge becomes invalid. After this date and time, the universal badge is revoked and no longer verifiable. For example, a health and safety badge may expire 3 years after the date of issue. ### Holder A holder is an entity or individual that holds and manages one or more universal badges. They have the ability to present, transfer, and delete badges as needed. ### Issuer An issuer is a trusted provider that creates, signs, and issues universal badges. They define the criteria and requirements for earning badges and can also revoke badges if necessary. ### Issuance Date The issuance date is the date on which a universal badge is issued. It marks the point at which the badge has been cryptographically signed and becomes a valid verifiable credential. ### Presentations Presentations involve a holder presenting one or more badges to a verifier. This can be done directly or within a verifiable presentation format. ### Proofs Proof is the cryptographic means of signing and verifying a Universal Badge. Issuers use standardized cryptographic methods, as outlined in the W3C standard for Verifiable Credential Data Model, to sign universal badges. This allows verifiers to cryptographically prove the validity of the claims presented in the badge. ### Revocation Revocation is the act of removing the verification proof of a universal badge, making it invalid and no longer verifiable. This can occur due to expired badges, accidental issuance, removal of endorsement, or other reasons. ### Selective Disclosure Selective disclosure refers to the ability of a badge holder to control which claims and data within a badge are disclosed to verifiers. It allows holders to share only the necessary information while protecting their privacy. ### Terms of Use Terms of Use are the legal guidelines for the use of a universal badge, as defined by the issuer. They may include legal guidelines, intellectual property rules, trademark or copyright regulations, general usage policies, or any other terms regarding the purpose and rightful use of the badge. ## Badge types *This section is non-normative.* This specification defines various badge types, each catering to distinct use-cases and supported by an extendible data model, providing flexibility in their application. The following badge types are outlined in this document: ### Accreditation An accreditation badge represents a measurable evaluated learning activity, such as a course, exam, or workshop. It encompasses different types of accreditations and indicates the level of the learning activity achieved. ### Achievement An achievement badge signifies a learner's successful accomplishment within a learning or vocational activity. It can include achievement descriptions, competencies, and benchmarks that demonstrate the learner's proficiency. ### Assertion An assertion badge serves as a qualitative representation of an achievement that cannot be formally evaluated. It encompasses recommendations, references, or statements about a subject. ### Completion A completion badge acknowledges the completion of specific tasks, milestones, events, workshops, or other achievements that may not be measurable through accreditations. ### Endorsement An endorsement badge signifies a qualitative representation of a subject's endorsement in relation to attributes such as skills, abilities, specific knowledge, or experiences. ### License A license badge is specifically representative of achievements that require licensing, such as completion of training in medical professions, authorization to sell alcohol, teaching qualifications, ELT (English Language Teaching), machine operations, and so on. ### Membership A membership badge denotes the subject's affiliation with organizations, clubs, working groups, unions, or other entities representing membership. ### Recognition A recognition badge acknowledges outstanding achievements or contributions made by the credential subject. It may encompass awards relating to volunteering, charity work, community contributions, outstanding work, employee of the month, etc. ### Skill A skill badge represents a subject's competency in a specific skill or ability. It can cover areas like 21st Century Skills, MSGs (Military Specialty Groups), Programming, Machine Operations, etc. ### Specialization A specialization badge represents a qualitative assessment of a subject's abilities in various specializations. It is issued by an issuer to signify expertise in specific areas. ## Stackable Badges *This section is non-normative.* The UB-SPEC supports the concept of stackable skills and the combining of universal badges, enabling a comprehensive representation of an individual's competencies and achievements. Stackable skills refer to the idea that badges can be earned and accumulated progressively, with each badge building upon previously acquired skills. This approach recognizes that learning and skill development often occur in a modular and interconnected manner. The UB-SPEC facilitates the combination of multiple universal badges to create a more holistic and nuanced representation of an individual's capabilities. By stacking badges, earners can demonstrate their progressive proficiency in a specific domain or showcase their mastery across a broader set of skills. Stacking badges can occur in various ways: - **Vertical Stacking** Vertical stacking involves earning badges in a sequential manner, with each badge representing a higher level of proficiency or mastery. For example, an individual may earn a series of badges that progressively demonstrate their knowledge and expertise from a beginner level to an advanced level within a particular skill or discipline. - **Lateral Stacking** Lateral stacking involves earning badges across different but related skills or domains. It allows individuals to showcase their diverse skill set and the ability to apply their knowledge in various contexts. For example, someone with badges in programming languages, data analysis, and project management can demonstrate their versatility in different areas of expertise. - **Nested Stacking** Nested stacking involves the combination of multiple badges that collectively represent a broader competency or specialization. In this case, badges can be earned at different levels within a specific skill or domain and then combined to showcase the overall proficiency in that area. For instance, badges in data visualization, graphical analysis, and statistical evaluation may be combined to demonstrate expertise in an advanced data analysis badge. The UB-SPEC provides the necessary infrastructure to support the stacking and combining of universal badges. The metadata associated with each badge, including the badge type, criteria, evidence, and issuer details, can enable verifiers to understand the individual components of the stacked badges and assess the earner's capabilities comprehensively. Stackable credentials and the combining of universal badges offers several benefits: - **Modularity and Flexibility** Stackable badges allow learners to pursue learning and skill development in smaller, manageable units, building upon their existing knowledge and accomplishments. This modularity offers flexibility in tailoring learning pathways to individual needs and interests. - **Incremental Progression** By earning and stacking badges, individuals can visually track their progress and see their skills grow over time. This incremental approach fosters motivation and encourages continued learning and achievement. - **Comprehensive Representation** The combination of badges provides a more holistic representation of an individual's competencies, highlighting their diverse skill set and multidimensional expertise. This comprehensive view allows for a better match between earners' capabilities and the requirements of educational programs, employment opportunities, or other contexts. - **Enhanced Credential Value** The stacking and combining of badges adds depth and richness to credentials, increasing their value and recognition. Verifiers can gain a deeper understanding of an individual's skills and accomplishments, leading to more informed decision-making in areas such as hiring, admissions, or professional development opportunities. --- # Universal Badge Data Models The following section outlines the data models for universal badges, along with guidelines for the flexible extention of these data models. The primary rules for all universal badges are as follows: A universal badge *MUST* adhere to the W3C Verifiable Credential Data Model recommendation. A universal badge *MUST* contain the Universal Badge Core Data Model properties. A universal badge *MAY* contain additional properties within the `issuer`, `credentialSubject`, or `badge` properties. #### An example universal badge may look like this: ```json { "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "http://example.edu/credentials/3732", "type": ["VerifiableCredential", "UniversalBadge"], "issuer": { "id": "did:method:example", "type": "Organization", "name": "An Example University", "logo": "https://www.exampleuni.com/logo.svg", "website": "https://www.exampleuni.com" }, "issuanceDate": "2010-01-01T19:23:24Z", "expirationDate": "2020-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "type": "Person", "name": "John Doe", "badge": { "type": "Assertion", "name": "Example Badge Title", "description": "The description of what the badge is for", "image": "ipfs://link.badge_image.svg", "assertion": { "id": "https://www.assertionexample.com/assertion.pdf", "type": "Personal reference", "description": "The detailed description of the assertion" } } }, "proof": { "type": "Ed25519Signature2018", "created": "2023-06-14T00:00:00Z", "proofPurpose": "assertionMethod", "verificationMethod": "did:example:123#key-1", "signatureValue": "Bavq3U9ab..." }, "credentialSchema": { "id": "https://example.com/schema.json" "type": "JsonSchemaValidator2018" }, "credentialStatus": { "id": "https://example.edu/status/24", "type": "CredentialStatusList2017" }, "evidence": [{ "id": "https://example.edu/evidence/f2aeec97-fc0d-42bf-8ca7-0548192d4231", "type": ["DocumentVerification"], "verifier": "https://example.edu/issuers/14", "evidenceDocument": "DriversLicense", "subjectPresence": "Physical", "documentPresence": "Physical", "licenseNumber": "123AB4567" }], "termsOfUse": [{ "type": "IssuerPolicy", "id": "http://example.com/policies/credential/4", "profile": "http://example.com/profiles/credential", }], } ``` ## Universal Badge Core Data Model The universal badge core data model outlines the properties that *SHOULD* be included in every universal badge. ### Contexts A universal badge *MUST* include the `@context` property. **@context** The value of the `@context` property *MUST* be an ordered set where the first item is a URI with the value `https://www.w3.org/2018/credentials/v1` and the secind item is a URI with the vale `https://reference-to-the-UB-SPEC`. Subsequent items in the array *MUST* express context information and be composed of any combination of URIs or objects. It is *RECOMMENDED* that each URI in the `@context` be one which, if dereferenced, results in a document containing machine-readable information about the `@context`. | Property | Type | Description | | --- | --- | --- | | @context | URI | A uniform resource identifier that references the context of the document. | #### Example ```json // "@context" type MUST be included and refers to the standardized context of this document "@context": [ "https://www.w3.org/2018/credentials/v1", // JSON-LD context for verifiable credentials "https://www.reference-to-the-UB-SPEC/v1" // JSON-LD context example for universal badges ], ``` ### Identifiers To enable the expression of unambiguous statements about specific entities, such as individuals or organizations, this specification uses the `id` property. The `id` property serves as an identifier that uniquely refers to an object within the universal badge context. **id** The value of the `id` property *MUST* be a single URI. It is *RECOMMENDED* that the URI used in the `id` property, when dereferenced, leads to a document or resource providing relevant machine readable information about the identified entity. The `id` property *MUST* represent an identifier that others are expected to utilize when expressing statements about the specific entity identified by that identifier. The value of the `id` property *MUST* be a URI (Uniform Resource Identifier). | Property | Type | Description | | --- | --- | --- | | id | URI | A uniform resource identifier that references the identity of the property it refers to. | #### Example ```json // "id" type MUST be included and specifies the identifier for the credential "id": "https://example.com/credentials/1234", // ID of Credential ``` ### Types Software systems that process the kinds of objects specified in this document use `type` information to determine whether or not a provided verifiable credential or verifiable presentation is appropriate. This specification defines a `type` property for the expression of `type` information. Universal badges and verifiable presentations of universal badges *MUST* have a `type` property. That is, any universal badge or presentation of a universal badge that does not have `type` property is not verifiable, so is neither a verifiable universal badge nor a verifiable presentation of a universal badge. **type** The value of the `type` property *MUST* be, or map to (through interpretation of the `@context` property), one or more URIs. If more than two URIs are provided, the URIs *MUST* be interpreted as an unordered set. Syntactic conveniences *SHOULD* be used to ease developer usage. Such conveniences might include JSON-LD terms. It is *RECOMMENDED* that each URI in the `type` be one which, if dereferenced, results in a document containing machine-readable information about the `type`. | Property | Type | Description | | --- | --- | --- | | Type | URI | A URI that provides further information on the property type it refers to. | #### Example ```json // "type" type MUST be included and refers to the type of verifiable credential and the data we can expect in the credential "type": ["VerifiableCredential", "UniversalBadge"], // Type of credential ``` ### Issuer A universal badge *MUST* include an `issuer` property. **issuer** The value of the `issuer` property is defined as a set of objects that contain one or more properties that are each related to the `issuer` of the universal badge. Within the `issuer` property are included `id`, `type`, `name`, `logo`, and `website` properties. The `issuer` property *MAY* also be extended to contain additional properties, as defined by the issuer of the badge, to provide more information about the issuer of the universal badge. See Extending the Data Models section. **id** The `issuer` property *MUST* include the `id` property. The value of the `id` property *MUST* be a single URI. See `id`. **type** The `issuer` property *MUST* include the `type` property. The value of the `type` property *MUST* be, or map to (through interpretation of the `@context` property), one or more URIs. See `type`. **name** The `issuer` property *MUST* include the `name` property. The value of the `name` property *MUST* be a text string containing the alias of the `issuer`. **logo** The `issuer` property *MAY* include the `logo` property. The value of the `logo` property *MUST* be a single URI that when dereferenced contains the image document of the issuer's logo image in svg or png format. **website** The `issuer` property *MAY* include the `website` property. The value of the `website` property *MUST* be a single URI that directs to the website of the `issuer`. | Property | Type | Description | | --- | --- | --- | | id | URI | A uniform resource identifier that references the identity of the issuer. | | type | URI | A URI that provides further information on the property type it refers to. | | name | text | A text string that contains the alias for the issuer. | | logo | URI | A URI that refers to the a linked image file of the issuer logo in png or svg file format. | | website | URI | A URI that refers to the issuers website. | #### Example ```json // "issuer" type MUST be included -- some sub-types are OPTIONAL and refers to the entity of the issuer of the badge "issuer": { "id": "did:method:example", // Identifier of the issuer "type": "Organization", // Type of the issuer "name": "An Example University", // Name of the issuer "logo": "https://www.exampleuni.com/logo.svg", // Logo of the issuer (OPTIONAL) "website": "https://www.exampleuni.com" // Website of the issuer (OPTIONAL) }, ``` ### Issuance Date A universal badge *MUST* include an `issuanceDate` property. **issuanceDate** The value of the `issuanceDate` property *MUST* be a string value of an [XMLSCHEMA11-2] combined date-time string representing the date and time the credential is signed and becomes valid. > Note that this value represents the earliest point in time at which the information associated with the `credentialSubject` property becomes valid. | Property | Type | Description | | --- | --- | --- | | issuanceDate | DateTimeZ | A combination of date and time of day that references the time and date the universal badge is valid from, in the form [-]CCYY-MM-DDThh:mm:ss[Z(+/-)hh:mm] (see ISO 8601). | #### Example ```json // "issuanceDate" type MUST be included and refers to the date and time the badge has been issued "issuanceDate": "2010-01-01T19:23:24Z", // date and time of the badge issuance ``` ### Expiration Date A universal badge *MAY* include an `expirationDate` property. **expirationDate** The value of the `expirationDate` property *MUST* be a string value of an [XMLSCHEMA11-2] combined date-time string representing the date and time the credential becomes invalid. The value of the `expirationDate` property *MUST* be a date and time in the future. > Note that this value represents the earliest point in time at which the information associated with the `credentialSubject` property becomes invalid. | Property | Type | Description | | --- | --- | --- | | expirationDate | DateTimeZ | A combination of date and time of day that references the time and the date the universal badge expires, in the form [-]CCYY-MM-DDThh:mm:ss[Z(+/-)hh:mm] (see ISO 8601). | #### Example ```json // "expirationDate" type is OPTIONAL and refers to the date in which the badge is no longer valid "expirationDate": "2020-01-01T19:23:24Z", // date and time on which the badge expires (OPTIONAL) ``` ### Credential Subject A universal badge *MUST* include a `credentialSubject` property. **credentialSubject** The value of the `credentialSubject` property `MUST` be a set of objects that contain one or more properties that each relate to the subject of the universal badge. A `credentialSubject` property *MAY* be extended to contain additional properties, as defined by the issuer of the badge, to provide more information and claims about the subject of the universal badge. See Extending the Data Models section. **id** The `credentalSubject` property *MUST* include the `id` property. The value of the `id` property *MUST* be a single URI. See `id`. **type** The `credentalSubject` property *MUST* include the `type` property. The value of the `type` property *MUST* be, or map to (through interpretation of the `@context` property), one or more URIs. See `type`. **name** The `credentalSubject` property *MAY* include the `name` property. The value of the `name` property *MUST* be a text string that references the alias of the `credentialSubject`. **badge** The `credentalSubject` property *MUST* include the `badge` property. The value of the `badge` property is defined as a set of objects that contain one or more properties that are each related to the claims made about the subject of the universal badge. The `badge` property *MUST* include `type`, `name`, and `description` properties. The `badge` property *MAY* include the `image` property. The `badge` property *MAY* also include additional properties as outlined in the badge type data models section of this document. The `badge` property *MAY* also be extended to contain additional properties as defined by the issuer of the badge to provide more information and claims about the subject of the universal badge. See Extending the Data Models section. #### Examples ```json // EXAMPLE of a basic universal badge // "credentialSubject" type MUST be included and refers to the claims made about the entity that is the subject of the badge "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", // identifier of the subject "type": "Person", // Type of the subject "name": "John Doe", // Name of the subject "badge": { // badge claims about the subject of the credential "type": "UniversalBadge", // Type of the badge as outlined in the Universal Badge Specification "name": "Example Badge Title", // Name of the badge "description": "The description of what the badge is for", // Description of the badge "image": "ipfs://link.badge_image.svg", // Image URL of the badge (for permanence it is recommended to store images in decentralized or distributed storage) ``` ```json // EXAMPLE of a universal badge with the assertion type // "credentialSubject" with additional properties referenced by the badge "type" property "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", // identifier of the subject "type": "Person", // Type of the subject "name": "John Doe", // Name of the subject "badge": { // badge claims about the subject of the credential "type": "Assertion", // Type of the badge as outlined in the Universal Badge Specification "name": "Example Badge Title", // Name of the badge "description": "The description of what the badge is for", // Description of the badge "image": "ipfs://link.badge_image.svg", // Image URL of the badge (for permanence it is recommended to store images in decentralized or distributed storage) // Additional metadata as determined by the chosen badge "type" outlined in the Universal Badge Specification "assertion": { "id": "https://www.assertionexample.com/assertion.pdf", // ID of the assertion (OPTIONAL) "type": "Personal reference", // Type of assertion "description": "The detailed description of the assertion" // Description of the assertion } ``` ### Proof At least one proof mechanism, and the details necessary to evaluate that proof, *MUST* be expressed for a universal badge to be verifiable. A universal badge *MUST* include the `proof` property. **proof** The `proof` property *MUST* contain one or more cryptographic proofs that can be used to detect tampering and verify the authorship of a universal badge. The specific method used for an embedded proof *MUST* be included using the `type` property. Because the method used for a mathematical proof varies by representation language and the technology used, the set of name-value pairs that is expected as the value of the `proof` property will vary accordingly. For example, if digital signatures are used for the proof mechanism, the `proof` property is expected to have name-value pairs that include a signature, a reference to the signing entity, and a representation of the signing date. The example below uses Ed25519 digital signature scheme. #### Example ```json // "proof" type MUST be included and refers to the cryptographic proofs that make the badge tamper evident "proof": { "type": "Ed25519Signature2018", // The cryptographic signature type that was used to generate the signature "created": "2023-06-14T00:00:00Z", // Date the signature was created "proofPurpose": "assertionMethod", // Purpose of the proof "verificationMethod": "did:example:9876#key-1", // The identifier of the public key that can verify the signature "signatureValue": "AbuTV27cd..." // The digital signature value ``` ### Credential Schema A universal badge *MAY* include the `credentialSchema` property. **credentialSchema** The value of the `credentialSchema` property *MUST* be one or more data schemas that provide enough information to determine if the provided data conforms to the provided schema. Each credentialSchema *MUST* contain its `type` property and `id` property. The `id` property *MUST* be a URI, which when dereferenced provides machine readable data that contains the schema information. The `type` property *MUST* express the credential schema type. The precise contents of each data schema is determined by the specific type definition. #### Example ```json // "credentialSchema" refers to the defined schema model for the universal badge it is contained within "credentialSchema": { "id": "https://example.com/schema.json", // ID of credentialSchema "type": "JsonSchemaValidator2018" // credentialSchema type }, ``` ### Credential Status A universal badge *MAY* include the `credentialStatus` property. **credentialStatus** If present, the value of the `credentialStatus` property *MUST* include the following: `id` property, which *MUST* be a URI. `type` property, which expresses the credential status type (also referred to as the credential status method). It is expected that the value will provide enough information to determine the current status of the credential and that machine readable information needs to be retrievable from the URI. For example, the object could contain a link to an external document noting whether or not the credential is suspended or revoked. #### Example ```json // "credentialStatus" type is OPTIONAL and refers to the ongoing status of a credential and whether it may be suspended or revoked "credentialStatus": { "id": "https://example.edu/status/24", // ID of credential status "type": "CredentialStatusList2017" // Credential Status type }, ``` ### Evidence Evidence can be included by an issuer to provide the verifier with additional supporting information in a universal badge. This could be used by the verifier to establish the confidence with which it relies on the claims within the universal badge. A universal badge *MAY* include the `evidence` property. **evidence** The value of the `evidence` property *MUST* be one or more evidence schemes providing enough information for a verifier to determine whether the evidence gathered by the issuer meets its confidence requirements for relying on the universal badge. Each evidence scheme is identified by its `type`. The `id` property is optional, but if present, *SHOULD* contain a URL that points to where more information about this instance of evidence can be found. The precise content of each evidence scheme is determined by the specific evidence type definition. #### Example ```json // "evidence" type is OPTIONAL and refers to any evidence that is associated with the process the credential subject has undergone in achieving their badge "evidence": [{ "id": "https://example.edu/evidence/f2aeec97-fc0d-42bf-8ca7-0548192d4231", // ID for evidence "type": ["DocumentVerification"], // Evidence type "verifier": "https://example.edu/issuers/14", // URI of the evidence verifier "evidenceDocument": "DriversLicense", // document provided for evidence (OPTIONAL) "subjectPresence": "Physical", // type of interaction - was the subject physically present or digitally present (OPTIONAL) "documentPresence": "Physical", // type of document presence - was the document physically shared or digitaly shared (OPTIONAL) "licenseNumber": "123AB4567" // license number of the evidence verifier (OPTIONAL) }], ``` ### Terms of Use Terms of use can be utilized by an issuer or a holder to communicate the terms under which a universal badge was issued. The issuer places their terms of use inside the universal badge. The holder places their terms of use inside a verifiable presentation. This specification defines a `termsOfUse` property for expressing terms of use information. A universal badge *MAY* include the `termsOfUse` property. **termsOfUse** The value of the `termsOfUse` property *MUST* specify one or more terms of use policies under which the creator issued the credential or presentation. Each `termsOfUse` value *MUST* specify its type, for example, `IssuerPolicy`, and *MAY* specify its instance `id`. The precise contents of each term of use is determined by the specific `termsOfUse` type definition. #### Example ```json // "termsOfUse" type is OPTIONAL and refers to any terms of use outlined in by the issuer in regard to the use of the badge "termsOfUse": [{ "type": "IssuerPolicy", // type of terms of use "id": "http://example.com/policies/credential/4", // URI id of terms of use "profile": "http://example.com/profiles/credential", // URI of terms of use profile }], ``` --- ## Badge Type Data Models This section of the UB-SPEC specifies the inclusion of standardized data models for different badge types. Each badge type requires the use of an additional data model, which *MUST* be incorporated when referencing the `credential.credentialSubject.badge.type` property of the universal badge core data model. A universal badge *MUST* include a `type` property within the `badge` property. In cases where no standardized data models are employed, the `credential.credentialSubject.badge.type` property *MUST* be set to `"UniversalBadge"` When utilizing a different badge `type`, the universal badge *MUST* assign the corresponding badge type value to the `type` property and *MUST* include the relevant additional data model specified within this section. ### Accreditation When using the accreditation data model the `type` value within the `badge` property *MUST* be `"Accreditation"` The `accreditation` property *MAY* also be extended to contain additional properties as defined by the issuer of the badge to provide more information and claims about the subject of the universal badge. See Extending the Data Models section. #### Example ```json "badge": { "type": "Accreditation", "name": "Example Badge Title", "description": "The description of what the badge is for", "image": "ipfs://link.badge_image.svg", "accreditation": [ "accreditingOrganization": { "id": "did:example:accreditor", // Identifier of the accrediting organization "type": "University", // Type of accrediting organization "name": "Example Accrediting Organization" // Name of the accrediting organization }, "accreditedBy": { "id": "did:example:accreditor", // OPTIONAL - Identifier of the organization that accredited "type": "Organization", // OPTIONAL - Type of the organization that accredited "name": "Example Accrediting Organization" // OPTIONAL - Name of the organization that accredited }, "accreditationType": "Professional Accreditation", // OPTIONAL - Type of accreditation "accreditationLevel": "Advanced" // OPTIONAL - Level of accreditation "accreditationCriteria": [ { "type": "Criteria", "description": "The criteria for earning the accreditation", "requiredCourses": [ "Course A", "Course B", "Course C" ], "minimumGrade": 70, "requiredHours": 120 } ], ], } ``` ### Achievement When using the achievement data model the `type` value within the `badge` property *MUST* be `"Achievement"` The `achievement` property *MAY* also be extended to contain additional properties as defined by the issuer of the badge to provide more information and claims about the subject of the universal badge. See Extending the Data Models section. #### Example ```json "badge": { "type": "Achievement", "name": "Example Badge Title", "description": "The description of what the badge is for", "image": "ipfs://link.badge_image.svg", "achievement": { "achievementType": "Attendance", // Type of achievement "achievementLevel": "100%", // OPTIONAL - Level of achievement "description": "This achievement acknowledges the holder has successfully achieved 100% attendence whilst participating in the event." // Description of the achievement }, } ``` ### Assertion When using the assertion data model the `type` value within the `badge` property *MUST* be `"Assertion"` The `assertion` property *MAY* also be extended to contain additional properties as defined by the issuer of the badge to provide more information and claims about the subject of the universal badge. See Extending the Data Models section. #### Example ```json "badge": { "type": "Assertion", "name": "Example Badge Title", "description": "The description of what the badge is for", "image": "ipfs://link.badge_image.svg", "assertion": { "id": "https://www.assertionexample.com/assertion.pdf", // OPTIONAL - ID of the assertion "type": "Personal reference", // Type of assertion "description": "The detailed description of the assertion" // Description of the assertion }, } ``` ### Completion When using the completion data model the `type` value within the `badge` property *MUST* be `"Completion"` The `completion` property *MAY* also be extended to contain additional properties as defined by the issuer of the badge to provide more information and claims about the subject of the universal badge. See Extending the Data Models section. #### Example ```json "badge": { "type": "Completion", "name": "Example Badge Title", "description": "The description of what the badge is for", "image": "ipfs://link.badge_image.svg", "completion": { "type": "Work Experience", // Type of completion "timeframe": "12 weeks", // Timeframe of completion "description": "An example description of the completed criteria, e.g., all required assignments and showed competent working skills." // Description of the completion }, } ``` ### Endorsement When using the endorsement data model the `type` value within the `badge` property *MUST* be `"Endorsement"` The `endorsement` property *MAY* also be extended to contain additional properties as defined by the issuer of the badge to provide more information and claims about the subject of the universal badge. See Extending the Data Models section. #### Example ```json "badge": { "type": "Endorsement", "name": "Example Badge Title", "description": "The description of what the badge is for", "image": "ipfs://link.badge_image.svg", "endorsement": [ "endorser": { "id": "did:example:789", // ID of the endorser "name": "Example Endorser", // Name of endorser }, "endorsement": { "description": "This badge endorses the recipient's achievements in a specific domain.", // Endorsement message or description "endorsementType": "Vocational reference" // Type of endorsement }, ], } ``` ### License When using the license data model the `type` value within the `badge` property *MUST* be `"License"` #### Example ```json "badge": { "type": "License", "name": "Example Badge Title", "description": "The description of what the badge is for", "image": "ipfs://link.badge_image.svg", "license": { "licenseType": "License to Sell Alcohol", // Type of license "licenseNumber": "ABC123", // License number "licenseCategory": "Tier3", // License category "description": "Additional information pertaining specifically to the training and licensing procedure and qualification process." // Description of the license }, } ``` ### Membership When using the membership data model the `type` value within the `badge` property *MUST* be `"Membership"` #### Example ```json "badge": { "type": "Membership", "name": "Example Badge Title", "description": "The description of what the badge is for", "image": "ipfs://link.badge_image.svg", "membership": { "name": "Example Community", // Name of the membership "membershipId": "123456", // Membership ID "membershipStartDate": "2022-01-01", // Start date of membership "membershipEndDate": "2023-12-31", // End date of membership "memberName": "John Doe", // Alias of the member "memberEmail": "john.doe@example.com", // OPTIONAL - Email of the member "website": "https://www.membership.com" // OPTIONAL - Website of the membership }, } ``` ### Recognition When using the recognition data model the `type` value within the `badge` property *MUST* be `"Recognition"` #### Example ```json "badge": { "type": "Recognition", "name": "Example Badge Title", "description": "The description of what the badge is for", "image": "ipfs://link.badge_image.svg", "recognition": { "id": "https://example.com/badges/recognition-badge", // ID of the recognition "name": "Volunteer Recognition Badge", // Name of the recognition "description": "This badge is awarded for outstanding contributions in the field of XYZ.", // Description of the recognition "criteria": "https://example.com/badges/recognition-badge-criteria" // OPTIONAL - Criteria for the recognition }, } ``` ### Skill When using the skill data model the `type` value within the `badge` property *MUST* be `"Skill"` #### Example ```json "badge": { "type": "Skill", "name": "Example Badge Title", "description": "The description of what the badge is for", "image": "ipfs://link.badge_image.svg", "skill": { "id": "https://example.com/skills/coding", // ID of the skill "name": "JSON Coding", // Name of the skill "skillLevel": "Advanced", // OPTIONAL - Representative level of the skill "description": "This skill referes to the holder's ability to be able to do something specific." // Description of the skill "skillFramework": { // OPTIONAL "id": "https://www.exampleframework.com/framework", // ID of the skill framework "name": "21st Century Skills" // Name of the skills framework the skill is a part of }, }, } ``` ### Specialization When using the specialization data model the `type` value within the `badge` property *MUST* be `"Specialization"` #### Example ```json "badge": { "type": "Specialization", "name": "Example Badge Title", "description": "The description of what the badge is for", "image": "ipfs://link.badge_image.svg", "specialization": { "name": "Electrical water purification", // Name of the specialization "level": "Advanced", // Level of the specialization "referer": "did:method:example", // Referer of the specialization "refererName": "Jane Doe" // Name of the referer "description": "Jane can purify water with electricity." // Description of the specialization. }, } ``` --- ## Additional Property Data Models In many cases, the requirement for additional properties *MAY* be included to add additional claims and information within the `credentialSubject`, `badge`, or `issuer` properties of a universal badge. In these cases, the following data models *MUST* be used when adding further properties. ### Address The `address` property *MAY* be used to represent a physical location reference within another property. The address property *MUST* follow the JSON format outlined in the schema.org address standard. The address property *MUST* include a combination of any, or all, of the properties outlined in the table below. | Property | Type | Description | | --- | --- | --- | | type | URI | The value of the `type` property *MUST* be an unordered set containing one or more URIs. See the `type` property description. | | addressCountry | Text | The country. For example, USA. | |addressCountryCode | CountryCode | A standardized country code. The value *MUST* be an alpha-2 country code as defined in [ISO3166-1] | | addressLocality | Text | The locality in which the street address is, usually a town or city, which is in the region. For example, Los Angeles. | | addressRegion | Text | The region in which the locality is, and which is in the country. For example, California or another appropriate first-level Administrative division. | | postOfficeBoxNumber | Text | When applicable, the post office box number for PO box addresses. | | postalCode | Text | The postal code. For example, 94043. | | streetAddress | Text | The street address. For example, 1600 Amphitheatre Pkwy | | geo | GeoCoordinates | The geographic coordinates of the location. This *MUST* include the longitude and latitude properties, that follow the WGS 84 standard. See Geo Coordinates. | #### Example ```json "address": { "type": "PostalAddress", "addressLocality": "Seattle", "addressRegion": "Washington", "postalCode": "98052", "streetAddress": "20341 Whitworth Institute 405 N. Whitworth" "addressCountry": "United States of America", "addressCountryCode": "US", "geo": { "latitude": "47.2649990", "longitude": "11.3428720" } } ``` ### Criteria The `criteria` property *MAY* be used to represent specific criteria within another property. #### Example ```json "criteria": { "id": "https://example.com/criteria", "type": "OccupationalCredential", "competencyRequired": [ { "type": "Competency", "description": "Demonstrated understanding of the subject matter.", "competencyText": "Subject Matter Expertise" } ], "educationalLevel": [ { "type": "DefinedTerm", "name": "Bachelor's Degree" } ], "learningTime": { "type": "Duration", "value": "360", "unitCode": "MIN" } }, ``` ### Email Address The `email` property *MAY* be used to represent an email address within another property. The `email` property *MUST* appear as a JSON object containing an internet mail standard address as outlined in [RFC 5321]. | Property | Type | Description | | --- | --- | --- | | email | Email Address | The email address of the property. | #### Example ```json "email": "someone@domain.com" ``` ### Geo Coordinates The `geo` property *MAY* be used to represent the geographical location of another property. The `geo` property *MUST* include the `longitude` and `latitude` properties that provide the geographic location of the property it refers to. The `longitude` and `latitude` properties *MUST* contain a numerical string that follows the WGS84 standard for geographic locators. | Property | Type | Description | | --- | --- | --- | | latitude | Number | A number string that represents the latitude coordinates of the geo property. | | longitude | Number | A number string that represents the longitude coordinates of the geo property. | #### Example 1 ```json "geo": { "latitude": "47.2649990", "longitude": "11.3428720" } ``` ### Image The `image` property *MAY* be used to represent an image file that relates to another property. The `image` property *MUST* include the `URI` and `name`properties. The `image` property *MAY* include the `description` and `caption` properties. The `URI` property *MUST* . The `name` property *MUST* contain a text string of the alias of the image. The `description` and `caption` properties *MUST* contain a text string containing a description and caption that refers to the image. | Property | Type | Description | | --- | --- | --- | | URI | URI | A URI that refers to the image file. | | name | Text | A text string of the alias of the image | | description | Text | A text string describing the image | | caption | Text | A text string of a caption for the image | #### Example 1 ```json "image": { "URI": "https://www.example.com/image.jpg", // The URI of the image "name": "My Image", // The name or alias of the image "description": "This describes the image and what it represents", // OPTIONAL - A description of the image "caption": "The image caption" // OPTIONAL - A brief caption to go alongside the image } ``` ### Tags The `tags` property *MAY* be used to represent any number of tags within another property. #### Example 1 ```json "tags": "certificate", "badge", "health and safety" ``` ### Website Address The `website` property *MAY* be used to represent a URI of a website within another property. | Property | Type | Description | | --- | --- | --- | | website | URI | A URI that refers to the website address of the property. | #### Example 1 ```json "website": "https://www.website.example" ``` --- ## Extending the Data Models Th UB-SPEC provides a versatile specification that is completely customizable, allowing badge creators the ability to extend data models freely to create unique and specific badges with their own collection of properties. In many cases, the requirements for additional information and unique data models not included within the UB-SPEC is neccessay to provide additional context and reference to the `credentialSubject`, `issuer`, or `badge` properties. A `credentialSubject`, `issuer`, or `badge` property *MAY* contain additional custom properties as defined by the creator of the universal badge, to represent additional information or claims about the `credentialSubject`, `issuer`, or `badge`. When adding custom properties within the `issuer`, `credentialSubject`, or `badge` properties the properties *MUST* follow the JSON Object Structure Format as outlined in the [ECMA-404] JSON data interchange syntax standard. Custom properties *MAY* only be added within the `credentialSubject`, `issuer`, or `badge` properties, or within other properties nested within these properties. #### Example ```json "exampleExtension": { "id": { "description": "The URI of the example extension", "key": "id", "value": "https://example.com/extension", "type": "URI" }, "name": { "description": "The name of the example extension", "key": "Name", "value": "Student Experiences", "type": "string" }, "competencies": { "description": "The competencies of the example extension", "key": "Competencies", "value": "Leadership", "Project Management", "Team Management", "type": "string" } } ``` --- ## Stacked Badge Data Models TBD ### Vertical Stacked Badges TBD ### Lateral Stacked Badges TBD ### Nested Stacked Badges TBD --- # Issuance and Verification Guidelines The issuance and verification of universal badges requires adherence to established guidelines and best practices to ensure the integrity, authenticity, and interoperability of universal badges throughout their lifecycle. These guidelines establish a framework for issuers and verifiers to follow when creating, issuing, and verifying universal badges. ## Metadata and contextual information Universal badges *SHOULD* include comprehensive metadata and contextual information to provide a clear understanding of the badge's purpose, significance, and criteria. The metadata *SHOULD* encompass details such as the badge name, description, image, issuer information (e.g., name, logo, website), and relevant criteria associated with the badge. This information allows recipients and verifiers to assess the badge's value and relevance accurately. The metadata included in a universal badge *MUST* conform to the appropriate data model and schema outlined in the UB-SPEC. The metadata included in a universal badge *MUST* conform to the W3C Verifiable Credential Data Model and adhere to the prescribed JSON-LD context and vocabulary. The contextual references within a universal badge *MUST* reference the W3C Verifiable Credential Data Model and the Universal Badge Specification. The contextual references within a universal badge *MAY* reference additional context. ## Badge creation and generation When creating a universal badge, issuers *MUST* follow the UB-SPEC process for defining the badge type and specifying the badge's properties. Badge creation *MAY* involve attaching relevant evidence, images, and supporting documentation that substantiate the claims made by the badge. This evidence *MAY* include links to artifacts, documents, assessments, files, or transcripts that validate the credential subject's achievements. By providing verifiable evidence, issuers enhance the credibility and trustworthiness of the universal badge. Issuers *MUST* ensure that the badge properties align with the specific data model and guidelines outlined in the corresponding badge type specification. ### Evidence and supporting documentation Universal badges *MAY* include evidence and supporting documentation that substantiate the claims made by the badge. This evidence can take various forms, including URLs or links to relevant documents, transcripts, assessments, projects, or other artifacts that validate the credential subject's achievements. The evidence *SHOULD* be provided in a verifiable format, enabling verifiers to access and assess the supporting materials to validate the badge's claims effectively. ### Digital signatures and cryptographic proofs Issuers *MUST* digitally sign a universal badge using standardised cryptographic methods, as outlined in the Verifiable Credential Data Model Standard. Verifiers *MUST* validate the digital signatures and cryptographic proofs to establish the trustworthiness of any universal badge. ## Issuance to holder The issuance of a universal badge to the intended holder *SHOULD* be carried out securely and reliably. This process *MAY* involve securely transmitting the badge to a holder, ensuring the privacy and confidentiality of the credential subject's data. Issuers *SHOULD* employ trusted channels and protocols for issuing badges, taking measures to protect the integrity and privacy of the badge during transit. ## Secure transmission and storage Universal badges *SHOULD* be transmitted and stored securely to prevent unauthorized access, tampering, or disclosure of sensitive information. Both issuers and verifiers *SHOULD* employ secure protocols and encryption mechanisms to protect the confidentiality and integrity of any universal badge during transmission and storage. > Secure transmission practices involve using encrypted channels, secure file transfer protocols, or secure messaging systems to transmit universal badges between issuers, holders, and verifiers. ## Holder control and visibility settings Universal badges *SHOULD* incorporate holder control and visibility settings that allow credential subjects to exercise control over their badge data. These settings can enable holders to define who can access and view their badges, providing them with privacy and control over the dissemination of their achievements and the data contained within. ### Selective disclosure of badge data Selective disclosure mechanisms, such as SD-JWT, *SHOULD* be used to allow holders to share specific badge data and claims with verifiers while keeping other details private. ## Universal badge verification Verifiers *MUST* follow established protocols and procedures to reliably verify a universal badge. Through the verification of cryptographic proofs, evidence, and metadata, it is possible to assess the overall trustworthiness and validity of the badge. ### Retrieval and interpretation of universal badges Verifiers *MUST* retrieve a universal badge or verifiable presentation of a universal badge from a holder using secure and reliable methods. A holder *MAY* present the entire badge or a verifiable presentation of the selected data required for the interaction. A retrieved badge *SHOULD* be interpreted based on the specified context, types, data models, and schema to extract relevant information and proofs required for the successful interpretation of the badge. ### Metadata validation Verifiers *MUST* validate the metadata associated within a universal badge to ensure its integrity, consistency, and compliance with the applicable data model and schema. Metadata validation *SHOULD* include verifying the context, types, and any additional contextual references to establish the validity and compatibility of the badge. --- # Baked Badges TBD ## Introduction TBD ## Selective disclosure TBD ## Creation of a baked badge TBD ## Privacy guidelines TBD ## Verification of baked badges TBD --- # Security and Privacy Considerations *This section is non-normative.* Security and privacy considerations are paramount when designing, implementing, and utilizing the UB-SPEC. This section provides non-normative guidance and recommendations on the various aspects of security and privacy that stakeholders should consider to protect the confidentiality, integrity, and privacy of universal badges and the associated credential data. When considering the data that may be included within a universal badge it is important to acknowledge the degree of privacy required when referring to different information. The W3C outlines a spectrum of privacy within the Verifiable Credential Data Model that recognizes the range of privacy from pseudonymous to strongly identified. In various scenarios, individuals often prefer to maintain a certain level of anonymity. For example, during a simple office job application process, the employer is solely focused on verifying whether an individual holds the required experience or skills for the role. A subject sharing their universal badges may not wish to disclose sensitive information that may be contained within these badges, such as geographical location, contact details, or age. On the other hand, a hospital that requires extensive background information to maintain a level of security within their hired staff may require further information, which an applicant may choose to disclose. Consequently, it becomes evident that a universal approach to privacy is insufficient for every situation. Privacy solutions need to be customised dependent upon the specific requirements for each individual use case. Like the W3C Verifiable Credential Data Model, the UB-SPEC strives to support the full spectrum of privacy, and does not define the correct level of anonymity for any specific transaction. The following sections offer considerations and guidance for implementers that may be of value when looking to avoid privacy endangering situations. ## Personally Identifiable Information *This section is non-normative.* The data associated with universal badges stored in the `credentialSubject` property is vulnerable to privacy breaches when shared with verifiers. Personally identifiable information (PII), such as a name, personal identifier, address, or contact information, can be easily utilized to identify, track, and correlate an individual. Even seemingly non-identifiable information, such as the combination of a birthdate and a postal code, possesses significant correlational and de-anonymization potential. It is strongly recommended that implementers caution holders when sharing data with such characteristics. Issuers are advised to prioritize the provision of privacy-protecting universal badges whenever feasible. For instance, when a verifier is only required to determine if an individual is above 18 years old, it is advisable to issue universal badges that contain an `ageOver` property instead of a `dateOfBirth` property. Given that a universal badge often contains personally identifiable information (PII), implementers are strongly encouraged to employ mechanisms for securely storing and transmitting these credentials, ensuring that unauthorized individuals cannot access the data. Potential mechanisms to consider include Transport Layer Security (TLS) or other encryption methods to safeguard the data during transit, as well as encryption or data access control mechanisms to protect the data within a universal badge when it is at rest. ## Pseudonymized Data *This section is non-normative.* Pseudonymized data, which involves replacing identifiable information with a pseudonym or a unique identifier, offers a potential solution to address privacy concerns when sharing sensitive information. By substituting personally identifiable badge data, such as names or addresses, with pseudonyms, individuals can maintain a level of anonymity while still allowing for data analysis and processing. However, it is important to recognize that even pseudonymized data can pose risks if certain characteristics are not properly managed. Although direct identification of individuals may be challenging, there is still a possibility of re-identification by combining pseudonymized data with other available information. Factors such as unique identifiers, temporal patterns, or distinctive attributes can inadvertently lead to the tracking, profiling, and identification of individuals. To mitigate these risks, implementers are strongly advised to adopt best practices when handling pseudonymized data. This includes employing strong pseudonymization techniques, ensuring the irreversible transformation of personal identifiers, and implementing robust access controls to limit data exposure. Additionally, it is crucial to establish clear policies and procedures for the use and sharing of pseudonymized data, ensuring compliance with relevant privacy regulations and standards. Furthermore, it is recommended that issuers regularly assess the effectiveness of their pseudonymization methods and consider the adoption of additional privacy-enhancing measures. These measures may include data minimization strategies, where only the necessary data is pseudonymized, and the implementation of privacy-preserving technologies like differential privacy to further safeguard sensitive information. ## Identifier-Based Correlation *This section is non-normative.* Subjects of universal badges are identified using the `id` property within the `credentialSubject` property. The use of unique identifiers that are long-lived or multi-domain to identify the subject of multiple badges can increase the risk of correlation. Similarly, the disclosure of the universal badge identifier can potentially result in collusion between multiple verifiers or between an issuer and a verifier, which can lead to the correlation of the badge subject or holder. To minimize correlation, holders should opt for verifiable credential schemes that allow hiding the identifier during the presentation of the badge. These schemes require the holder to generate the identifier and may even permit concealing it from the issuer, while ensuring that the identifier remains embedded and signed in the universal badge. In universal badge ecosystems where strong anti-correlation properties are necessary, it is highly recommended that identifiers are either: - Bound to a single origin, - Single-use, or - Not used at all, but instead replaced by short-lived, single-use bearer tokens. ## Data protection and minimization *This section is non-normative.* The protection of personal data and the minimization of data collection are essential considerations when designing and implementing universal badges. Respecting individuals' privacy rights and complying with data protection regulations are crucial for establishing trust and maintaining the integrity of the credentialing ecosystem. In the context of universal badges, data protection involves implementing appropriate measures to safeguard personal information, while data minimization focuses on collecting and processing only the necessary data required for issuing, verifying, and presenting badges. By adopting these practices, stakeholders can mitigate privacy risks, reduce the potential for unauthorized access or data breaches, and enhance individuals' control over their personal data. Considerations in this regard include: * **Data Minimization:** Collect and process only the minimum amount of personal data necessary to fulfill the purpose of issuing, verifying, and presenting universal badges. Avoid the inclusion of unnecessary or excessive personal information that may increase privacy risks. * **Anonymization and Pseudonymization:** Employ techniques such as anonymization and pseudonymization to mitigate privacy risks associated with the use of personal data. Anonymization involves removing or encrypting personally identifiable information (PII) from the badge data, while pseudonymization replaces identifiable information with pseudonyms to protect individuals' identities. * **Secure Data Storage:** Ensure universal badges are stored securely using industry-standard encryption mechanisms, access controls, and secure storage protocols. Implement encryption at rest to protect badge data from unauthorized access in storage environments, and encryption in transit to secure the transmission of badges over networks. * **Retention Limitation:** Define and adhere to appropriate data retention periods for universal badges. Retain badge data only for as long as necessary to fulfill the intended purpose, taking into account legal and regulatory requirements. Regularly review and dispose of expired or unnecessary data to minimize privacy risks. * **Data Subject Rights:** Respect individuals' data subject rights and provide mechanisms for credential holders to exercise their rights. This includes enabling individuals to access, rectify, erase, and port their badge data, as well as providing transparency about the data processing activities associated with universal badges. ## Consent and user control *This section is non-normative.* Respecting user control and obtaining informed consent are paramount to upholding privacy rights and promoting user autonomy. Universal badges contain valuable personal information, making it crucial to prioritize user control and to respect an individuals' autonomy in managing their badge data. By incorporating robust consent and user control mechanisms through best practices, standards, and frameworks it is possible to ensure that individuals have agency over their badge data and can make informed decisions regarding its collection, processing, and sharing. Considerations in this area include: * **Informed Consent:** Obtaining explicit and informed consent from badge subjects and holders is a fundamental principle of responsible data management. When collecting and processing badge data, it is essential to clearly communicate the purpose, scope, and potential uses of the data. Individuals should be provided with comprehensive information to make informed decisions regarding the sharing and disclosure of their badge information. * **Privacy Settings and Controls:** Providing granular privacy settings and controls is key to empowering credential holders and respecting their preferences. Users should have the ability to customize the visibility and accessibility of their badge data, determining which verifiers or relying parties can access their credentials. * **User Notification:** Transparent and timely communication with credential holders regarding any changes or updates to their badge data is crucial. Notification mechanisms should be established to inform individuals about modifications, revocations, or any other pertinent changes related to their credentials. * **Withdrawal of Consent:** Allowing users to easily withdraw their consent and revoke access to their badge data is a fundamental aspect of user control. Individuals should have the right to change their mind and decide not to share their credentials with specific verifiers or relying parties. Enabling the withdrawal of consent reinforces user autonomy and ensures that individuals can exercise control over their personal information. ## Secure storage and transmission *This section is non-normative.* Secure storage mechanisms are vital to safeguarding universal badges from unauthorized access, tampering, and loss. When considering secure storage, it is important to adhere to industry-accepted standards, encryption protocols, access controls, and backup procedures. Key considerations include: * **Secure Transmission:** Transmit universal badges over secure channels, such as encrypted connections (e.g., HTTPS), to prevent interception and tampering during transmission. Follow established security best practices and utilize secure protocols. * **Secure Storage:** Employ secure storage mechanisms to protect universal badges from unauthorized access. This may include encrypted databases, hardware wallets, or trusted credential management systems that adhere to industry-accepted security standards. * **Backup and Disaster Recovery:** Establish secure backup and disaster recovery procedures to ensure the availability and integrity of universal badges in case of system failures, hardware malfunctions, or natural disasters. Regularly perform backups and verify the integrity of backup data to enable swift recovery in the event of data loss or corruption. * **Access Controls:** Implement strong access controls to restrict access to Universal Badges only to authorized personnel or systems. Role-based access control (RBAC), multi-factor authentication (MFA), and principle of least privilege should be employed to limit access rights and minimize the risk of insider threats. * **Authentication and Identity Verification:** Employ strong authentication mechanisms during transmission to verify the identities of the parties involved in the exchange of universal badges. Use digital signatures, cryptographic proofs, and decentralized identifiers (DIDs) to ensure the authenticity and non-repudiation of the sender and recipient. ## Cryptographic mechanisms and digital signatures *This section is non-normative.* Cryptographic mechanisms and digital signatures play a pivotal role in the security and integrity of universal badges. These mechanisms provide strong assurances of authenticity, integrity, and non-repudiation, establishing trust among verifiers, issuers, and holders. By employing robust cryptographic techniques, stakeholders can ensure that universal badges cannot be tampered with or fraudulently altered, enabling reliable verification and fostering confidence in the credentialing ecosystem. When implementing cryptographic mechanisms and digital signatures for universal badges, adherence to recognized standards and best practices is crucial. The W3C Verifiable Credential Data Model, DID-CORE, and SD-JWT provide valuable guidelines and recommendations in this regard. It is essential to utilize cryptographic algorithms and protocols that are widely recognized and accepted within the specifications to ensure the long-term security and resilience of universal badges. Considerations in this area include: * **Digital Signatures:** Apply digital signatures in line with the W3C Verifiable Credential Data Model recommendation to universal badges to ensure well-established cryptographic algorithms and standards. * **Key Management:** Implement robust key management practices to safeguard cryptographic keys used for signing and verification. Protect private keys from unauthorized access and ensure key rotation and revocation mechanisms are in place. * **Cryptographic Algorithms:** Use strong and widely accepted cryptographic algorithms for signing and encryption to ensure the long-term security and resilience of universal badges. Stay updated with industry standards and best practices regarding cryptographic algorithms. ## Privacy-by-design principles *This section is non-normative.* Privacy-by-design emphasizes the proactive integration of privacy considerations into every aspect of the badge ecosystem to ensure the protection of individuals' privacy and data confidentiality. The goal of privacy by design is to embed privacy-enhancing measures from the initial stages of badge system design, rather than addressing privacy as an afterthought or bolt-on feature. This approach acknowledges that privacy is not just a legal compliance requirement but a fundamental human right that should be respected and upheld throughout the lifecycle of universal badges. Privacy-by-design key considerations include: * **Privacy as the Default:** Privacy settings and safeguards should be implemented by default, minimizing the collection, use, and disclosure of personal data. Default settings should prioritize the highest level of privacy protection, empowering individuals with control over their data and limiting data sharing to what is necessary and explicitly authorized. * **Data Protection Impact Assessment (DPIA):** Conducting DPIA helps to identify and mitigate privacy risks associated with any universal badge development. Assessing the potential impact on individuals' privacy and allowing the opportunity to implement appropriate measures that minimize risks. * **Anonymity and Pseudonymity:** Promote anonymity and pseudonymity wherever possible to protect the privacy of credential subjects and holders. Avoid unnecessary collection and processing of PII, and provide options for users to interact within the universal badges ecosystem using pseudonymous or anonymous identifiers. * **Data Security and Privacy Training:** Provide comprehensive training and awareness programs to stakeholders involved in the issuance, verification, and management of universal badges. Educate personnel about data security, privacy best practices, and their roles and responsibilities in protecting badge data. ## Compliance with privacy regulations *This section is non-normative.* As universal badges contain PII and pseudonymous identifiers, it is crucial to ensure that their issuance, verification, and usage comply with relevant privacy regulations. Compliance with privacy regulations not only protects the privacy rights of individuals but also establishes trust in the use of universal badges. It is important to be aware of jurisdiction and to understand the privacy laws of not only key international states and unions, but to also be aware of the more regional regulations that may apply to specific geographic locations. It is essential for stakeholders involved in any universal badge ecosystem to be fully aware of and adhere to the regulations that apply to their specific use case and jurisdiction, to ensure the privacy and security of individuals' personal information. > **This section does not act as legal guidance**, but rather provides insights and considerations on a number of key privacy regulations that govern the collection, processing, and sharing of personal data. #### General Data Protection Regulation (GDPR) The General Data Protection Regulation (GDPR) is a comprehensive privacy regulation that applies to the processing of personal data of individuals within the European Union (EU) and European Economic Area (EEA). Key principles and requirements under the GDPR include: * **Lawful Processing:** Ensure that the processing of personal data for universal badges is conducted lawfully and with a valid legal basis, such as consent, contract performance, or legitimate interests. * **Informed Consent:** Obtain informed and explicit consent from individuals for the collection, processing, and sharing of their personal data. Clearly communicate the purposes and scope of data processing to individuals. * **Data Subject Rights:** Respect the rights of data subjects, including the right to access, rectification, erasure, and data portability. Enable individuals to exercise these rights regarding their universal badge data. * **Data Protection Impact Assessment (DPIA):** Conduct a DPIA to assess and mitigate privacy risks associated with universal badges. Identify and address potential risks to individuals' rights and freedoms. * **Cross-Border Data Transfers:** Ensure that any transfer of personal data outside the EU/EEA is done in compliance with GDPR requirements, such as using appropriate safeguards or obtaining individuals' explicit consent. #### California Consumer Privacy Act (CCPA) The California Consumer Privacy Act (CCPA) is a privacy law that grants California residents specific rights regarding the collection, processing, and sharing of their personal information. Key considerations under the CCPA include: * **Transparency:** Provide clear and easily accessible privacy notices that inform individuals about the collection and use of their personal data for universal badges. * **Right to Opt-Out:** Offer individuals the right to opt-out of the sale or sharing of their personal information. Provide mechanisms for individuals to exercise this right. * **Consumer Privacy Rights:** Respect the privacy rights of California residents, including the right to know, delete, and access personal information. Enable individuals to exercise these rights concerning their universal badge data. * **Non-Discrimination:** Avoid discriminatory practices against individuals who exercise their CCPA rights. Treat all individuals equally, regardless of their exercise of privacy rights. #### Other Privacy Regulations In addition to GDPR and CCPA, there are various other privacy regulations that may apply depending on the jurisdiction and the nature of universal badge usage. Some examples include: * **Personal Information Protection and Electronic Documents Act (PIPEDA)** in Canada * **Health Insurance Portability and Accountability Act (HIPAA)** in the United States * **Data Protection Act** in the United Kingdom Stakeholders should familiarize themselves with the relevant privacy regulations in their respective jurisdictions and ensure compliance with applicable requirements. This may involve implementing privacy policies, terms of use, practices, and technical safeguards to protect personal data and fulfill the obligations outlined in these regulations. --- # Use Cases --- # Examples --- # Next Steps and Future Developments --- # References **[DID-CORE]** Decentralized Identifiers (DIDs) v1.0. Manu Sporny; Amy Guy; Markus Sabadello; Drummond Reed. W3C. 19 July 2022. W3C Recommendation. URL: https://www.w3.org/TR/did-core/ **[ISO 21778:2017]** Information technology — The JSON data interchange syntax. ISO/IEC. November 2017. URL: https://www.iso.org/standard/71616.html **[ISO 3166-1]** Country Codes. ISO/IEC. August 2020. URL: https://www.iso.org/standard/72482.html **[ISO 8601]** Date and time format/ ISO/IEC. February 2019. URL: https://www.iso.org/standard/70907.html **[JSON-LD]** JSON-LD 1.1: A JSON-based Serialization for Linked Data. Gregg Kellogg; Manu Sporny; Dave Longley; Markus Lanthaler; Pierre-Antoine Champin; Niklas Lindström. W3C JSON-LD 1.1 Working Group. W3C Working Draft. URL: https://www.w3.org/TR/json-ld11/ **[RFC2119]** Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119 **[RFC3986]** Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3986 **[RFC5321]** Simple Mail Transfer Protocol. J. Klensin; IETF. October 2008. UEL: https://datatracker.ietf.org/doc/html/rfc5321 **[RFC7515]** JSON Web Signature (JWS). M. Jones; J. Bradley; N. Sakimura. IETF. May 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7515 **[RFC7519]** JSON Web Token (JWT). M. Jones; J. Bradley; N. Sakimura. IETF. May 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7519 **[RFC8174]** Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174 **[RFC8259]** The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. IETF. December 2017. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc8259 **[VC-DATA-MODEL]** Verifiable Credentials Data Model v1.1. Manu Sporny; Grant Noble; Dave Longley; Daniel Burnett; Brent Zundel; Kyle Den Hartog. W3C. 3 March 2022. W3C Recommendation. URL: https://www.w3.org/TR/vc-data-model/ **[WGS84]** WORLD GEODETIC SYSTEM 1984 (WGS 84). DoD:NGA. July 2014. URL: https://earth-info.nga.mil/index.php?dir=wgs84&action=wgs84 **[XMLSCHEMA11-2]** W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. W3C. 5 April 2012. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema11-2/