# data[].attributes.body
1Edtech Open Badge v3 candidate final

# data[].attributes.attachment_link.readable_text
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://purl.imsglobal.org/spec/ob/v3p0/context.json",
    "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "http://1edtech.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "OpenBadgeCredential"
  ],
  "name": "1EdTech University Degree for Example Student",
  "description": "1EdTech University Degree Description",
  "image": {
    "id": "https://1edtech.edu/credentials/3732/image",
    "type": "Image",
    "caption": "1EdTech University Degree for Example Student"
  },
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "type": "AchievementSubject",
    "activityEndDate": "2010-01-02T00:00:00Z",
    "activityStartDate": "2010-01-01T00:00:00Z",
    "creditsEarned": 42,
    "licenseNumber": "A-9320041",
    "role": "Major Domo",
    "source": {
      "id": "https://school.edu/issuers/201234",
      "type": "Profile",
      "name": "1EdTech College of Arts"
    },
    "term": "Fall",
    "identifier": [
      {
        "type": "IdentityObject",
        "identityHash": "student@1edtech.edu",
        "identityType": "emailAddress",
        "hashed": false,
        "salt": "not-used"
      },
      {
        "type": "IdentityObject",
        "identityHash": "somebody@gmail.com",
        "identityType": "emailAddress",
        "hashed": false,
        "salt": "not-used"
      }
    ],
    "achievement": {
      "id": "https://1edtech.edu/achievements/degree",
      "type": "Achievement",
      "alignment": [
        {
          "type": "Alignment",
          "targetCode": "degree",
          "targetDescription": "1EdTech University Degree programs.",
          "targetName": "1EdTech University Degree",
          "targetFramework": "1EdTech University Program and Course Catalog",
          "targetType": "CFItem",
          "targetUrl": "https://1edtech.edu/catalog/degree"
        },
        {
          "type": "Alignment",
          "targetCode": "degree",
          "targetDescription": "1EdTech University Degree programs.",
          "targetName": "1EdTech University Degree",
          "targetFramework": "1EdTech University Program and Course Catalog",
          "targetType": "CTDL",
          "targetUrl": "https://credentialengineregistry.org/resources/ce-98cb027b-95ef-4494-908d-6f7790ec6b6b"
        }
      ],
      "achievementType": "Degree",
      "creator": {
        "id": "https://1edtech.edu/issuers/565049",
        "type": "Profile",
        "name": "1EdTech University",
        "url": "https://1edtech.edu",
        "phone": "1-222-333-4444",
        "description": "1EdTech University provides online degree programs.",
        "endorsement": [
          {
            "@context": [
              "https://www.w3.org/2018/credentials/v1",
              "https://purl.imsglobal.org/spec/ob/v3p0/context.json",
              "https://w3id.org/security/suites/ed25519-2020/v1"
            ],
            "id": "http://1edtech.edu/endorsementcredential/3732",
            "type": [
              "VerifiableCredential",
              "EndorsementCredential"
            ],
            "issuer": {
              "id": "https://accrediter.edu/issuers/565049",
              "type": "Profile",
              "name": "Example Accrediting Agency"
            },
            "issuanceDate": "2010-01-01T00:00:00Z",
            "expirationDate": "2020-01-01T00:00:00Z",
            "credentialSubject": {
              "id": "https://1edtech.edu/issuers/565049",
              "type": "EndorsementSubject",
              "endorsementComment": "1EdTech University is in good standing"
            },
            "credentialSchema": [
              {
                "id": "https://purl.imsglobal.org/spec/ob/v3p0/schema/json/ob_v3p0_endorsementcredential_schema.json",
                "type": "1EdTechJsonSchemaValidator2019"
              },
              {
                "id": "https://accrediter.edu/schema/endorsementcredential.json",
                "type": "1EdTechJsonSchemaValidator2019"
              }
            ],
            "credentialStatus": {
              "id": "https://1edtech.edu/credentials/3732/revocations",
              "type": "1EdTechRevocationList"
            },
            "refreshService": {
              "id": "http://1edtech.edu/credentials/3732",
              "type": "1EdTechCredentialRefresh"
            },
            "proof": [
              {
                "type": "Ed25519Signature2020",
                "created": "2022-05-26T18:17:08Z",
                "verificationMethod": "https://accrediter.edu/issuers/565049#zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA",
                "proofPurpose": "assertionMethod",
                "proofValue": "zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA"
              }
            ]
          },
          {
            "@context": [
              "https://www.w3.org/2018/credentials/v1",
              "https://purl.imsglobal.org/spec/ob/v3p0/context.json",
              "https://w3id.org/security/suites/ed25519-2020/v1"
            ],
            "id": "http://1edtech.edu/endorsementcredential/3733",
            "type": [
              "VerifiableCredential",
              "EndorsementCredential"
            ],
            "issuer": {
              "id": "https://state.gov/issuers/565049",
              "type": "Profile",
              "name": "State Department of Education"
            },
            "issuanceDate": "2010-01-01T00:00:00Z",
            "expirationDate": "2020-01-01T00:00:00Z",
            "credentialSubject": {
              "id": "https://1edtech.edu/issuers/565049",
              "type": "EndorsementSubject",
              "endorsementComment": "1EdTech University is in good standing"
            },
            "credentialSchema": [
              {
                "id": "https://purl.imsglobal.org/spec/ob/v3p0/schema/json/ob_v3p0_endorsementcredential_schema.json",
                "type": "1EdTechJsonSchemaValidator2019"
              },
              {
                "id": "https://state.gov/schema/endorsementcredential.json",
                "type": "1EdTechJsonSchemaValidator2019"
              }
            ],
            "credentialStatus": {
              "id": "https://state.gov/credentials/3732/revocations",
              "type": "1EdTechRevocationList"
            },
            "refreshService": {
              "id": "http://state.gov/credentials/3732",
              "type": "1EdTechCredentialRefresh"
            },
            "proof": [
              {
                "type": "Ed25519Signature2020",
                "created": "2022-05-26T18:25:59Z",
                "verificationMethod": "https://accrediter.edu/issuers/565049#z5bDnmSgDczXwZGya6ZjxKaxkdKxzsCMiVSsgEVWxnaWK7ZqbKnzcCd7mUKE9DQaAL2QMXP5AquPeW6W2CWrZ7jNC",
                "proofPurpose": "assertionMethod",
                "proofValue": "z5bDnmSgDczXwZGya6ZjxKaxkdKxzsCMiVSsgEVWxnaWK7ZqbKnzcCd7mUKE9DQaAL2QMXP5AquPeW6W2CWrZ7jNC"
              }
            ]
          }
        ],
        "image": {
          "id": "https://1edtech.edu/logo.png",
          "type": "Image",
          "caption": "1EdTech University logo"
        },
        "email": "registrar@1edtech.edu",
        "address": {
          "type": [
            "Address"
          ],
          "addressCountry": "USA",
          "addressCountryCode": "US",
          "addressRegion": "TX",
          "addressLocality": "Austin",
          "streetAddress": "123 First St",
          "postOfficeBoxNumber": "1",
          "postalCode": "12345",
          "geo": {
            "type": "GeoCoordinates",
            "latitude": 1,
            "longitude": 1
          }
        },
        "otherIdentifier": [
          {
            "type": "IdentifierEntry",
            "identifier": "12345",
            "identifierType": "sourcedId"
          },
          {
            "type": "IdentifierEntry",
            "identifier": "67890",
            "identifierType": "nationalIdentityNumber"
          }
        ],
        "official": "Horace Mann",
        "parentOrg": {
          "id": "did:example:123456789",
          "type": "Profile",
          "name": "Universal Universities"
        }
      },
      "creditsAvailable": 36,
      "criteria": {
        "id": "https://1edtech.edu/achievements/degree",
        "narrative": "# Degree Requirements\nStudents must complete..."
      },
      "description": "1EdTech University Degree Description",
      "endorsement": [
        {
          "@context": [
            "https://www.w3.org/2018/credentials/v1",
            "https://purl.imsglobal.org/spec/ob/v3p0/context.json",
            "https://w3id.org/security/suites/ed25519-2020/v1"
          ],
          "id": "http://1edtech.edu/endorsementcredential/3734",
          "type": [
            "VerifiableCredential",
            "EndorsementCredential"
          ],
          "issuer": {
            "id": "https://accrediter.edu/issuers/565049",
            "type": "Profile",
            "name": "Example Accrediting Agency"
          },
          "issuanceDate": "2010-01-01T00:00:00Z",
          "expirationDate": "2020-01-01T00:00:00Z",
          "credentialSubject": {
            "id": "https://1edtech.edu/issuers/565049",
            "type": "EndorsementSubject",
            "endorsementComment": "1EdTech University is in good standing"
          },
          "credentialSchema": [
            {
              "id": "https://purl.imsglobal.org/spec/ob/v3p0/schema/json/ob_v3p0_endorsementcredential_schema.json",
              "type": "1EdTechJsonSchemaValidator2019"
            },
            {
              "id": "https://accrediter.edu/schema/endorsementcredential.json",
              "type": "1EdTechJsonSchemaValidator2019"
            }
          ],
          "credentialStatus": {
            "id": "https://1edtech.edu/credentials/3732/revocations",
            "type": "1EdTechRevocationList"
          },
          "refreshService": {
            "id": "http://1edtech.edu/credentials/3732",
            "type": "1EdTechCredentialRefresh"
          },
          "proof": [
            {
              "type": "Ed25519Signature2020",
              "created": "2022-05-26T18:17:08Z",
              "verificationMethod": "https://accrediter.edu/issuers/565049#zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA",
              "proofPurpose": "assertionMethod",
              "proofValue": "zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA"
            }
          ]
        }
      ],
      "fieldOfStudy": "Research",
      "humanCode": "R1",
      "image": {
        "id": "https://1edtech.edu/achievements/degree/image",
        "type": "Image",
        "caption": "1EdTech University Degree"
      },
      "name": "1EdTech University Degree",
      "otherIdentifier": [
        {
          "type": "IdentifierEntry",
          "identifier": "abde",
          "identifierType": "identifier"
        }
      ],
      "resultDescription": [
        {
          "id": "urn:uuid:f6ab24cd-86e8-4eaf-b8c6-ded74e8fd41c",
          "type": "ResultDescription",
          "alignment": [
            {
              "type": "Alignment",
              "targetCode": "project",
              "targetDescription": "Project description",
              "targetName": "Final Project",
              "targetFramework": "1EdTech University Program and Course Catalog",
              "targetType": "CFItem",
              "targetUrl": "https://1edtech.edu/catalog/degree/project"
            }
          ],
          "allowedValue": [
            "D",
            "C",
            "B",
            "A"
          ],
          "name": "Final Project Grade",
          "requiredValue": "C",
          "resultType": "LetterGrade"
        },
        {
          "id": "urn:uuid:a70ddc6a-4c4a-4bd8-8277-cb97c79f40c5",
          "type": "ResultDescription",
          "alignment": [
            {
              "type": "Alignment",
              "targetCode": "project",
              "targetDescription": "Project description",
              "targetName": "Final Project",
              "targetFramework": "1EdTech University Program and Course Catalog",
              "targetType": "CFItem",
              "targetUrl": "https://1edtech.edu/catalog/degree/project"
            }
          ],
          "allowedValue": [
            "D",
            "C",
            "B",
            "A"
          ],
          "name": "Final Project Grade",
          "requiredLevel": "urn:uuid:d05a0867-d0ad-4b03-bdb5-28fb5d2aab7a",
          "resultType": "RubricCriterionLevel",
          "rubricCriterionLevel": [
            {
              "id": "urn:uuid:d05a0867-d0ad-4b03-bdb5-28fb5d2aab7a",
              "type": "RubricCriterionLevel",
              "alignment": [
                {
                  "type": "Alignment",
                  "targetCode": "project",
                  "targetDescription": "Project description",
                  "targetName": "Final Project",
                  "targetFramework": "1EdTech University Program and Course Catalog",
                  "targetType": "CFRubricCriterionLevel",
                  "targetUrl": "https://1edtech.edu/catalog/degree/project/rubric/levels/mastered"
                }
              ],
              "description": "The author demonstrated...",
              "level": "Mastered",
              "name": "Mastery",
              "points": "4"
            },
            {
              "id": "urn:uuid:6b84b429-31ee-4dac-9d20-e5c55881f80e",
              "type": "RubricCriterionLevel",
              "alignment": [
                {
                  "type": "Alignment",
                  "targetCode": "project",
                  "targetDescription": "Project description",
                  "targetName": "Final Project",
                  "targetFramework": "1EdTech University Program and Course Catalog",
                  "targetType": "CFRubricCriterionLevel",
                  "targetUrl": "https://1edtech.edu/catalog/degree/project/rubric/levels/basic"
                }
              ],
              "description": "The author demonstrated...",
              "level": "Basic",
              "name": "Basic",
              "points": "4"
            }
          ]
        },
        {
          "id": "urn:uuid:b07c0387-f2d6-4b65-a3f4-f4e4302ea8f7",
          "type": "ResultDescription",
          "name": "Project Status",
          "resultType": "Status"
        }
      ],
      "specialization": "Computer Science Research",
      "tag": [
        "research",
        "computer science"
      ]
    },
    "image": {
      "id": "https://1edtech.edu/credentials/3732/image",
      "type": "Image",
      "caption": "1EdTech University Degree for Example Student"
    },
    "narrative": "There is a final project report and source code evidence.",
    "result": [
      {
        "type": [
          "Result"
        ],
        "alignment": [
          {
            "type": "Alignment",
            "targetCode": "project",
            "targetDescription": "Project description",
            "targetName": "Final Project",
            "targetFramework": "1EdTech University Program and Course Catalog",
            "targetType": "CFItem",
            "targetUrl": "https://1edtech.edu/catalog/degree/project/result/1"
          }
        ],
        "resultDescription": "urn:uuid:f6ab24cd-86e8-4eaf-b8c6-ded74e8fd41c",
        "value": "A"
      },
      {
        "type": [
          "Result"
        ],
        "achievedLevel": "urn:uuid:d05a0867-d0ad-4b03-bdb5-28fb5d2aab7a",
        "alignment": [
          {
            "type": "Alignment",
            "targetCode": "project",
            "targetDescription": "Project description",
            "targetName": "Final Project",
            "targetFramework": "1EdTech University Program and Course Catalog",
            "targetType": "CFItem",
            "targetUrl": "https://1edtech.edu/catalog/degree/project/result/1"
          }
        ],
        "resultDescription": "urn:uuid:f6ab24cd-86e8-4eaf-b8c6-ded74e8fd41c"
      },
      {
        "type": [
          "Result"
        ],
        "resultDescription": "urn:uuid:f6ab24cd-86e8-4eaf-b8c6-ded74e8fd41c",
        "status": "Completed"
      }
    ]
  },
  "endorsement": [
    {
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://purl.imsglobal.org/spec/ob/v3p0/context.json",
        "https://w3id.org/security/suites/ed25519-2020/v1"
      ],
      "id": "http://1edtech.edu/endorsementcredential/3735",
      "type": [
        "VerifiableCredential",
        "EndorsementCredential"
      ],
      "issuer": {
        "id": "https://accrediter.edu/issuers/565049",
        "type": "Profile",
        "name": "Example Accrediting Agency"
      },
      "issuanceDate": "2010-01-01T00:00:00Z",
      "expirationDate": "2020-01-01T00:00:00Z",
      "credentialSubject": {
        "id": "https://1edtech.edu/issuers/565049",
        "type": "EndorsementSubject",
        "endorsementComment": "1EdTech University is in good standing"
      },
      "credentialSchema": [
        {
          "id": "https://purl.imsglobal.org/spec/ob/v3p0/schema/json/ob_v3p0_endorsementcredential_schema.json",
          "type": "1EdTechJsonSchemaValidator2019"
        },
        {
          "id": "https://accrediter.edu/schema/endorsementcredential.json",
          "type": "1EdTechJsonSchemaValidator2019"
        }
      ],
      "credentialStatus": {
        "id": "https://1edtech.edu/credentials/3732/revocations",
        "type": "1EdTechRevocationList"
      },
      "refreshService": {
        "id": "http://1edtech.edu/credentials/3732",
        "type": "1EdTechCredentialRefresh"
      },
      "proof": [
        {
          "type": "Ed25519Signature2020",
          "created": "2022-05-26T18:17:08Z",
          "verificationMethod": "https://accrediter.edu/issuers/565049#zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA",
          "proofPurpose": "assertionMethod",
          "proofValue": "zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA"
        }
      ]
    }
  ],
  "evidence": [
    {
      "id": "https://1edtech.edu/credentials/3732/evidence/1",
      "type": "Evidence",
      "narrative": "# Final Project Report \n This project was ...",
      "name": "Final Project Report",
      "description": "This is the final project report.",
      "genre": "Research",
      "audience": "Department"
    },
    {
      "id": "https://github.com/somebody/project",
      "type": "Evidence",
      "name": "Final Project Code",
      "description": "This is the source code for the final project app.",
      "genre": "Research",
      "audience": "Department"
    }
  ],
  "issuer": {
    "id": "https://1edtech.edu/issuers/565049",
    "type": "Profile",
    "name": "1EdTech University",
    "url": "https://1edtech.edu",
    "phone": "1-222-333-4444",
    "description": "1EdTech University provides online degree programs.",
    "endorsement": [
      {
        "@context": [
          "https://www.w3.org/2018/credentials/v1",
          "https://purl.imsglobal.org/spec/ob/v3p0/context.json",
          "https://w3id.org/security/suites/ed25519-2020/v1"
        ],
        "id": "http://1edtech.edu/endorsementcredential/3736",
        "type": [
          "VerifiableCredential",
          "EndorsementCredential"
        ],
        "issuer": {
          "id": "https://accrediter.edu/issuers/565049",
          "type": "Profile",
          "name": "Example Accrediting Agency"
        },
        "issuanceDate": "2010-01-01T00:00:00Z",
        "expirationDate": "2020-01-01T00:00:00Z",
        "credentialSubject": {
          "id": "https://1edtech.edu/issuers/565049",
          "type": "EndorsementSubject",
          "endorsementComment": "1EdTech University is in good standing"
        },
        "credentialSchema": [
          {
            "id": "https://purl.imsglobal.org/spec/ob/v3p0/schema/json/ob_v3p0_endorsementcredential_schema.json",
            "type": "1EdTechJsonSchemaValidator2019"
          },
          {
            "id": "https://accrediter.edu/schema/endorsementcredential.json",
            "type": "1EdTechJsonSchemaValidator2019"
          }
        ],
        "credentialStatus": {
          "id": "https://1edtech.edu/credentials/3732/revocations",
          "type": "1EdTechRevocationList"
        },
        "refreshService": {
          "id": "http://1edtech.edu/credentials/3732",
          "type": "1EdTechCredentialRefresh"
        },
        "proof": [
          {
            "type": "Ed25519Signature2020",
            "created": "2022-05-26T18:17:08Z",
            "verificationMethod": "https://accrediter.edu/issuers/565049#zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA",
            "proofPurpose": "assertionMethod",
            "proofValue": "zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA"
          }
        ]
      }
    ],
    "image": {
      "id": "https://1edtech.edu/logo.png",
      "type": "Image",
      "caption": "1EdTech University logo"
    },
    "email": "registrar@1edtech.edu",
    "address": {
      "type": [
        "Address"
      ],
      "addressCountry": "USA",
      "addressCountryCode": "US",
      "addressRegion": "TX",
      "addressLocality": "Austin",
      "streetAddress": "123 First St",
      "postOfficeBoxNumber": "1",
      "postalCode": "12345",
      "geo": {
        "type": "GeoCoordinates",
        "latitude": 1,
        "longitude": 1
      }
    },
    "otherIdentifier": [
      {
        "type": "IdentifierEntry",
        "identifier": "12345",
        "identifierType": "sourcedId"
      },
      {
        "type": "IdentifierEntry",
        "identifier": "67890",
        "identifierType": "nationalIdentityNumber"
      }
    ],
    "official": "Horace Mann",
    "parentOrg": {
      "id": "did:example:123456789",
      "type": "Profile",
      "name": "Universal Universities"
    }
  },
  "issuanceDate": "2010-01-01T00:00:00Z",
  "expirationDate": "2030-01-01T00:00:00Z",
  "credentialSchema": [
    {
      "id": "https://purl.imsglobal.org/spec/ob/v3p0/schema/json/ob_v3p0_achievementcredential_schema.json",
      "type": "1EdTechJsonSchemaValidator2019"
    }
  ],
  "credentialStatus": {
    "id": "https://1edtech.edu/credentials/3732/revocations",
    "type": "1EdTechRevocationList"
  },
  "refreshService": {
    "id": "http://1edtech.edu/credentials/3732",
    "type": "1EdTechCredentialRefresh"
  },
  "proof": [
    {
      "type": "Ed25519Signature2020",
      "created": "2022-12-15T16:56:16Z",
      "verificationMethod": "https://1edtech.edu/issuers/565049#z6MkqyURPYHv1KqmuB31DzajrRU1tHK6fPy7DJK7H4i5tDto",
      "proofPurpose": "assertionMethod",
      "proofValue": "z4QfZcRAVTm4rVtyxd288NzNLvvPgG9eBbSVDtCLZfmsJZFyFjarz5Lp8T7XvBxY5wgenkfEwrsBwmTLjzUkxUaGp"
    }
  ]
}

---------------- JWT header ---------------
{
  "alg": "RS256",
  "typ": "JWT",
  "jwk": {
    "e": "AQAB",
    "kty": "RSA",
    "n": "tRxHOGGQxXhohU0DnU2DmxS1ZnnKoqCCjOaKow-EKBYKvsnJxLz7qMCTzZ1I3qYabxPLkp
TwZmOKbB49Ua9SkczL6-VPX9nUAv8DMtHPwXn7hIigxAei7snJFXj8eceNh9dGZv_k0bOK4XSA2qqUxR
9YLXDJ8bcLDKxx7ukcfMeOvuEgOOYya44LBPCvKXz536OqkTkjMvd8-s1H0k5A39d6O9f_DF7EnQDOJF
Ok_D7Fh-xjWZojKhxayyYOX2CWch4gyNBMAj3N0TTHBOm9uXBMdyNtR_8m5jT29vhniWPhNTfwbnYHeg
ZxSmPmWqdGxzOzWihQXxeQyawgO8UItw"
  }
}
--------------- JWT payload ---------------
// NOTE: The example below uses a valid VC-JWT serialization
//       that duplicates the iss, nbf, jti, and sub fields in the
//       Verifiable Credential (vc) field.
{
  "vc": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://purl.imsglobal.org/spec/ob/v3p0/context.json",
      "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
    ],
    "id": "http://1edtech.edu/credentials/3732",
    "type": [
      "VerifiableCredential",
      "OpenBadgeCredential"
    ],
    "name": "1EdTech University Degree for Example Student",
    "description": "1EdTech University Degree Description",
    "image": {
      "id": "https://1edtech.edu/credentials/3732/image",
      "type": "Image",
      "caption": "1EdTech University Degree for Example Student"
    },
    "credentialSubject": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "type": "AchievementSubject",
      "activityEndDate": "2010-01-02T00:00:00Z",
      "activityStartDate": "2010-01-01T00:00:00Z",
      "creditsEarned": 42,
      "licenseNumber": "A-9320041",
      "role": "Major Domo",
      "source": {
        "id": "https://school.edu/issuers/201234",
        "type": "Profile",
        "name": "1EdTech College of Arts"
      },
      "term": "Fall",
      "identifier": [
        {
          "type": "IdentityObject",
          "identityHash": "student@1edtech.edu",
          "identityType": "emailAddress",
          "hashed": false,
          "salt": "not-used"
        },
        {
          "type": "IdentityObject",
          "identityHash": "somebody@gmail.com",
          "identityType": "emailAddress",
          "hashed": false,
          "salt": "not-used"
        }
      ],
      "achievement": {
        "id": "https://1edtech.edu/achievements/degree",
        "type": "Achievement",
        "alignment": [
          {
            "type": "Alignment",
            "targetCode": "degree",
            "targetDescription": "1EdTech University Degree programs.",
            "targetName": "1EdTech University Degree",
            "targetFramework": "1EdTech University Program and Course Catalog",
            "targetType": "CFItem",
            "targetUrl": "https://1edtech.edu/catalog/degree"
          },
          {
            "type": "Alignment",
            "targetCode": "degree",
            "targetDescription": "1EdTech University Degree programs.",
            "targetName": "1EdTech University Degree",
            "targetFramework": "1EdTech University Program and Course Catalog",
            "targetType": "CTDL",
            "targetUrl": "https://credentialengineregistry.org/resources/ce-98cb
027b-95ef-4494-908d-6f7790ec6b6b"
          }
        ],
        "achievementType": "Degree",
        "creator": {
          "id": "https://1edtech.edu/issuers/565049",
          "type": "Profile",
          "name": "1EdTech University",
          "url": "https://1edtech.edu",
          "phone": "1-222-333-4444",
          "description": "1EdTech University provides online degree programs.",
          "endorsement": [
            {
              "@context": [
                "https://www.w3.org/2018/credentials/v1",
                "https://purl.imsglobal.org/spec/ob/v3p0/context.json",
                "https://w3id.org/security/suites/ed25519-2020/v1"
              ],
              "id": "http://1edtech.edu/endorsementcredential/3732",
              "type": [
                "VerifiableCredential",
                "EndorsementCredential"
              ],
              "issuer": {
                "id": "https://accrediter.edu/issuers/565049",
                "type": "Profile",
                "name": "Example Accrediting Agency"
              },
              "issuanceDate": "2010-01-01T00:00:00Z",
              "expirationDate": "2020-01-01T00:00:00Z",
              "credentialSubject": {
                "id": "https://1edtech.edu/issuers/565049",
                "type": "EndorsementSubject",
                "endorsementComment": "1EdTech University is in good standing"
              },
              "credentialSchema": [
                {
                  "id": "https://purl.imsglobal.org/spec/ob/v3p0/schema/json/ob_
v3p0_endorsementcredential_schema.json",
                  "type": "1EdTechJsonSchemaValidator2019"
                },
                {
                  "id": "https://accrediter.edu/schema/endorsementcredential.jso
n",
                  "type": "1EdTechJsonSchemaValidator2019"
                }
              ],
              "credentialStatus": {
                "id": "https://1edtech.edu/credentials/3732/revocations",
                "type": "1EdTechRevocationList"
              },
              "refreshService": {
                "id": "http://1edtech.edu/credentials/3732",
                "type": "1EdTechCredentialRefresh"
              },
              "proof": [
                {
                  "type": "Ed25519Signature2020",
                  "created": "2022-05-26T18:17:08Z",
                  "verificationMethod": "https://accrediter.edu/issuers/565049#z
vPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5
sWRYgtA",
                  "proofPurpose": "assertionMethod",
                  "proofValue": "zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCA
wQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA"
                }
              ]
            },
            {
              "@context": [
                "https://www.w3.org/2018/credentials/v1",
                "https://purl.imsglobal.org/spec/ob/v3p0/context.json",
                "https://w3id.org/security/suites/ed25519-2020/v1"
              ],
              "id": "http://1edtech.edu/endorsementcredential/3733",
              "type": [
                "VerifiableCredential",
                "EndorsementCredential"
              ],
              "issuer": {
                "id": "https://state.gov/issuers/565049",
                "type": "Profile",
                "name": "State Department of Education"
              },
              "issuanceDate": "2010-01-01T00:00:00Z",
              "expirationDate": "2020-01-01T00:00:00Z",
              "credentialSubject": {
                "id": "https://1edtech.edu/issuers/565049",
                "type": "EndorsementSubject",
                "endorsementComment": "1EdTech University is in good standing"
              },
              "credentialSchema": [
                {
                  "id": "https://purl.imsglobal.org/spec/ob/v3p0/schema/json/ob_
v3p0_endorsementcredential_schema.json",
                  "type": "1EdTechJsonSchemaValidator2019"
                },
                {
                  "id": "https://state.gov/schema/endorsementcredential.json",
                  "type": "1EdTechJsonSchemaValidator2019"
                }
              ],
              "credentialStatus": {
                "id": "https://state.gov/credentials/3732/revocations",
                "type": "1EdTechRevocationList"
              },
              "refreshService": {
                "id": "http://state.gov/credentials/3732",
                "type": "1EdTechCredentialRefresh"
              },
              "proof": [
                {
                  "type": "Ed25519Signature2020",
                  "created": "2022-05-26T18:25:59Z",
                  "verificationMethod": "https://accrediter.edu/issuers/565049#z
5bDnmSgDczXwZGya6ZjxKaxkdKxzsCMiVSsgEVWxnaWK7ZqbKnzcCd7mUKE9DQaAL2QMXP5AquPeW6W2
CWrZ7jNC",
                  "proofPurpose": "assertionMethod",
                  "proofValue": "z5bDnmSgDczXwZGya6ZjxKaxkdKxzsCMiVSsgEVWxnaWK7Z
qbKnzcCd7mUKE9DQaAL2QMXP5AquPeW6W2CWrZ7jNC"
                }
              ]
            }
          ],
          "image": {
            "id": "https://1edtech.edu/logo.png",
            "type": "Image",
            "caption": "1EdTech University logo"
          },
          "email": "registrar@1edtech.edu",
          "address": {
            "type": [
              "Address"
            ],
            "addressCountry": "USA",
            "addressCountryCode": "US",
            "addressRegion": "TX",
            "addressLocality": "Austin",
            "streetAddress": "123 First St",
            "postOfficeBoxNumber": "1",
            "postalCode": "12345",
            "geo": {
              "type": "GeoCoordinates",
              "latitude": 1,
              "longitude": 1
            }
          },
          "otherIdentifier": [
            {
              "type": "IdentifierEntry",
              "identifier": "12345",
              "identifierType": "sourcedId"
            },
            {
              "type": "IdentifierEntry",
              "identifier": "67890",
              "identifierType": "nationalIdentityNumber"
            }
          ],
          "official": "Horace Mann",
          "parentOrg": {
            "id": "did:example:123456789",
            "type": "Profile",
            "name": "Universal Universities"
          }
        },
        "creditsAvailable": 36,
        "criteria": {
          "id": "https://1edtech.edu/achievements/degree",
          "narrative": "# Degree Requirements\nStudents must complete..."
        },
        "description": "1EdTech University Degree Description",
        "endorsement": [
          {
            "@context": [
              "https://www.w3.org/2018/credentials/v1",
              "https://purl.imsglobal.org/spec/ob/v3p0/context.json",
              "https://w3id.org/security/suites/ed25519-2020/v1"
            ],
            "id": "http://1edtech.edu/endorsementcredential/3734",
            "type": [
              "VerifiableCredential",
              "EndorsementCredential"
            ],
            "issuer": {
              "id": "https://accrediter.edu/issuers/565049",
              "type": "Profile",
              "name": "Example Accrediting Agency"
            },
            "issuanceDate": "2010-01-01T00:00:00Z",
            "expirationDate": "2020-01-01T00:00:00Z",
            "credentialSubject": {
              "id": "https://1edtech.edu/issuers/565049",
              "type": "EndorsementSubject",
              "endorsementComment": "1EdTech University is in good standing"
            },
            "credentialSchema": [
              {
                "id": "https://purl.imsglobal.org/spec/ob/v3p0/schema/json/ob_v3
p0_endorsementcredential_schema.json",
                "type": "1EdTechJsonSchemaValidator2019"
              },
              {
                "id": "https://accrediter.edu/schema/endorsementcredential.json"
,
                "type": "1EdTechJsonSchemaValidator2019"
              }
            ],
            "credentialStatus": {
              "id": "https://1edtech.edu/credentials/3732/revocations",
              "type": "1EdTechRevocationList"
            },
            "refreshService": {
              "id": "http://1edtech.edu/credentials/3732",
              "type": "1EdTechCredentialRefresh"
            },
            "proof": [
              {
                "type": "Ed25519Signature2020",
                "created": "2022-05-26T18:17:08Z",
                "verificationMethod": "https://accrediter.edu/issuers/565049#zvP
kQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sW
RYgtA",
                "proofPurpose": "assertionMethod",
                "proofValue": "zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQ
HqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA"
              }
            ]
          }
        ],
        "fieldOfStudy": "Research",
        "humanCode": "R1",
        "image": {
          "id": "https://1edtech.edu/achievements/degree/image",
          "type": "Image",
          "caption": "1EdTech University Degree"
        },
        "name": "1EdTech University Degree",
        "otherIdentifier": [
          {
            "type": "IdentifierEntry",
            "identifier": "abde",
            "identifierType": "identifier"
          }
        ],
        "resultDescription": [
          {
            "id": "urn:uuid:f6ab24cd-86e8-4eaf-b8c6-ded74e8fd41c",
            "type": "ResultDescription",
            "alignment": [
              {
                "type": "Alignment",
                "targetCode": "project",
                "targetDescription": "Project description",
                "targetName": "Final Project",
                "targetFramework": "1EdTech University Program and Course Catalo
g",
                "targetType": "CFItem",
                "targetUrl": "https://1edtech.edu/catalog/degree/project"
              }
            ],
            "allowedValue": [
              "D",
              "C",
              "B",
              "A"
            ],
            "name": "Final Project Grade",
            "requiredValue": "C",
            "resultType": "LetterGrade"
          },
          {
            "id": "urn:uuid:a70ddc6a-4c4a-4bd8-8277-cb97c79f40c5",
            "type": "ResultDescription",
            "alignment": [
              {
                "type": "Alignment",
                "targetCode": "project",
                "targetDescription": "Project description",
                "targetName": "Final Project",
                "targetFramework": "1EdTech University Program and Course Catalo
g",
                "targetType": "CFItem",
                "targetUrl": "https://1edtech.edu/catalog/degree/project"
              }
            ],
            "allowedValue": [
              "D",
              "C",
              "B",
              "A"
            ],
            "name": "Final Project Grade",
            "requiredLevel": "urn:uuid:d05a0867-d0ad-4b03-bdb5-28fb5d2aab7a",
            "resultType": "RubricCriterionLevel",
            "rubricCriterionLevel": [
              {
                "id": "urn:uuid:d05a0867-d0ad-4b03-bdb5-28fb5d2aab7a",
                "type": "RubricCriterionLevel",
                "alignment": [
                  {
                    "type": "Alignment",
                    "targetCode": "project",
                    "targetDescription": "Project description",
                    "targetName": "Final Project",
                    "targetFramework": "1EdTech University Program and Course Ca
talog",
                    "targetType": "CFRubricCriterionLevel",
                    "targetUrl": "https://1edtech.edu/catalog/degree/project/rub
ric/levels/mastered"
                  }
                ],
                "description": "The author demonstrated...",
                "level": "Mastered",
                "name": "Mastery",
                "points": "4"
              },
              {
                "id": "urn:uuid:6b84b429-31ee-4dac-9d20-e5c55881f80e",
                "type": "RubricCriterionLevel",
                "alignment": [
                  {
                    "type": "Alignment",
                    "targetCode": "project",
                    "targetDescription": "Project description",
                    "targetName": "Final Project",
                    "targetFramework": "1EdTech University Program and Course Ca
talog",
                    "targetType": "CFRubricCriterionLevel",
                    "targetUrl": "https://1edtech.edu/catalog/degree/project/rub
ric/levels/basic"
                  }
                ],
                "description": "The author demonstrated...",
                "level": "Basic",
                "name": "Basic",
                "points": "4"
              }
            ]
          },
          {
            "id": "urn:uuid:b07c0387-f2d6-4b65-a3f4-f4e4302ea8f7",
            "type": "ResultDescription",
            "name": "Project Status",
            "resultType": "Status"
          }
        ],
        "specialization": "Computer Science Research",
        "tag": [
          "research",
          "computer science"
        ]
      },
      "image": {
        "id": "https://1edtech.edu/credentials/3732/image",
        "type": "Image",
        "caption": "1EdTech University Degree for Example Student"
      },
      "narrative": "There is a final project report and source code evidence.",
      "result": [
        {
          "type": [
            "Result"
          ],
          "alignment": [
            {
              "type": "Alignment",
              "targetCode": "project",
              "targetDescription": "Project description",
              "targetName": "Final Project",
              "targetFramework": "1EdTech University Program and Course Catalog"
,
              "targetType": "CFItem",
              "targetUrl": "https://1edtech.edu/catalog/degree/project/result/1"
            }
          ],
          "resultDescription": "urn:uuid:f6ab24cd-86e8-4eaf-b8c6-ded74e8fd41c",
          "value": "A"
        },
        {
          "type": [
            "Result"
          ],
          "achievedLevel": "urn:uuid:d05a0867-d0ad-4b03-bdb5-28fb5d2aab7a",
          "alignment": [
            {
              "type": "Alignment",
              "targetCode": "project",
              "targetDescription": "Project description",
              "targetName": "Final Project",
              "targetFramework": "1EdTech University Program and Course Catalog"
,
              "targetType": "CFItem",
              "targetUrl": "https://1edtech.edu/catalog/degree/project/result/1"
            }
          ],
          "resultDescription": "urn:uuid:f6ab24cd-86e8-4eaf-b8c6-ded74e8fd41c"
        },
        {
          "type": [
            "Result"
          ],
          "resultDescription": "urn:uuid:f6ab24cd-86e8-4eaf-b8c6-ded74e8fd41c",
          "status": "Completed"
        }
      ]
    },
    "endorsement": [
      {
        "@context": [
          "https://www.w3.org/2018/credentials/v1",
          "https://purl.imsglobal.org/spec/ob/v3p0/context.json",
          "https://w3id.org/security/suites/ed25519-2020/v1"
        ],
        "id": "http://1edtech.edu/endorsementcredential/3735",
        "type": [
          "VerifiableCredential",
          "EndorsementCredential"
        ],
        "issuer": {
          "id": "https://accrediter.edu/issuers/565049",
          "type": "Profile",
          "name": "Example Accrediting Agency"
        },
        "issuanceDate": "2010-01-01T00:00:00Z",
        "expirationDate": "2020-01-01T00:00:00Z",
        "credentialSubject": {
          "id": "https://1edtech.edu/issuers/565049",
          "type": "EndorsementSubject",
          "endorsementComment": "1EdTech University is in good standing"
        },
        "credentialSchema": [
          {
            "id": "https://purl.imsglobal.org/spec/ob/v3p0/schema/json/ob_v3p0_e
ndorsementcredential_schema.json",
            "type": "1EdTechJsonSchemaValidator2019"
          },
          {
            "id": "https://accrediter.edu/schema/endorsementcredential.json",
            "type": "1EdTechJsonSchemaValidator2019"
          }
        ],
        "credentialStatus": {
          "id": "https://1edtech.edu/credentials/3732/revocations",
          "type": "1EdTechRevocationList"
        },
        "refreshService": {
          "id": "http://1edtech.edu/credentials/3732",
          "type": "1EdTechCredentialRefresh"
        },
        "proof": [
          {
            "type": "Ed25519Signature2020",
            "created": "2022-05-26T18:17:08Z",
            "verificationMethod": "https://accrediter.edu/issuers/565049#zvPkQiU
FfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgt
A",
            "proofPurpose": "assertionMethod",
            "proofValue": "zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7
fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA"
          }
        ]
      }
    ],
    "evidence": [
      {
        "id": "https://1edtech.edu/credentials/3732/evidence/1",
        "type": "Evidence",
        "narrative": "# Final Project Report \n This project was ...",
        "name": "Final Project Report",
        "description": "This is the final project report.",
        "genre": "Research",
        "audience": "Department"
      },
      {
        "id": "https://github.com/somebody/project",
        "type": "Evidence",
        "name": "Final Project Code",
        "description": "This is the source code for the final project app.",
        "genre": "Research",
        "audience": "Department"
      }
    ],
    "issuer": {
      "id": "https://1edtech.edu/issuers/565049",
      "type": "Profile",
      "name": "1EdTech University",
      "url": "https://1edtech.edu",
      "phone": "1-222-333-4444",
      "description": "1EdTech University provides online degree programs.",
      "endorsement": [
        {
          "@context": [
            "https://www.w3.org/2018/credentials/v1",
            "https://purl.imsglobal.org/spec/ob/v3p0/context.json",
            "https://w3id.org/security/suites/ed25519-2020/v1"
          ],
          "id": "http://1edtech.edu/endorsementcredential/3736",
          "type": [
            "VerifiableCredential",
            "EndorsementCredential"
          ],
          "issuer": {
            "id": "https://accrediter.edu/issuers/565049",
            "type": "Profile",
            "name": "Example Accrediting Agency"
          },
          "issuanceDate": "2010-01-01T00:00:00Z",
          "expirationDate": "2020-01-01T00:00:00Z",
          "credentialSubject": {
            "id": "https://1edtech.edu/issuers/565049",
            "type": "EndorsementSubject",
            "endorsementComment": "1EdTech University is in good standing"
          },
          "credentialSchema": [
            {
              "id": "https://purl.imsglobal.org/spec/ob/v3p0/schema/json/ob_v3p0
_endorsementcredential_schema.json",
              "type": "1EdTechJsonSchemaValidator2019"
            },
            {
              "id": "https://accrediter.edu/schema/endorsementcredential.json",
              "type": "1EdTechJsonSchemaValidator2019"
            }
          ],
          "credentialStatus": {
            "id": "https://1edtech.edu/credentials/3732/revocations",
            "type": "1EdTechRevocationList"
          },
          "refreshService": {
            "id": "http://1edtech.edu/credentials/3732",
            "type": "1EdTechCredentialRefresh"
          },
          "proof": [
            {
              "type": "Ed25519Signature2020",
              "created": "2022-05-26T18:17:08Z",
              "verificationMethod": "https://accrediter.edu/issuers/565049#zvPkQ
iUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHqG7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRY
gtA",
              "proofPurpose": "assertionMethod",
              "proofValue": "zvPkQiUFfJrgnCRhyPkTSkgrGXbnLR15pHH5HZVYNdM4TCAwQHq
G7fMeMPLtYNRnEgoV1aJdR5E61eWu5sWRYgtA"
            }
          ]
        }
      ],
      "image": {
        "id": "https://1edtech.edu/logo.png",
        "type": "Image",
        "caption": "1EdTech University logo"
      },
      "email": "registrar@1edtech.edu",
      "address": {
        "type": [
          "Address"
        ],
        "addressCountry": "USA",
        "addressCountryCode": "US",
        "addressRegion": "TX",
        "addressLocality": "Austin",
        "streetAddress": "123 First St",
        "postOfficeBoxNumber": "1",
        "postalCode": "12345",
        "geo": {
          "type": "GeoCoordinates",
          "latitude": 1,
          "longitude": 1
        }
      },
      "otherIdentifier": [
        {
          "type": "IdentifierEntry",
          "identifier": "12345",
          "identifierType": "sourcedId"
        },
        {
          "type": "IdentifierEntry",
          "identifier": "67890",
          "identifierType": "nationalIdentityNumber"
        }
      ],
      "official": "Horace Mann",
      "parentOrg": {
        "id": "did:example:123456789",
        "type": "Profile",
        "name": "Universal Universities"
      }
    },
    "issuanceDate": "2010-01-01T00:00:00Z",
    "expirationDate": "2030-01-01T00:00:00Z",
    "credentialSchema": [
      {
        "id": "https://purl.imsglobal.org/spec/ob/v3p0/schema/json/ob_v3p0_achie
vementcredential_schema.json",
        "type": "1EdTechJsonSchemaValidator2019"
      }
    ],
    "credentialStatus": {
      "id": "https://1edtech.edu/credentials/3732/revocations",
      "type": "1EdTechRevocationList"
    },
    "refreshService": {
      "id": "http://1edtech.edu/credentials/3732",
      "type": "1EdTechCredentialRefresh"
    }
  },
  "exp": 1893456000,
  "iss": "https://1edtech.edu/issuers/565049",
  "nbf": 1262304000,
  "jti": "http://1edtech.edu/credentials/3732",
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21"
}
--------------- JWT ---------------
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImp3ayI6eyJlIjoiQVFBQiIsImt0eSI6IlJTQSIsIm4i
OiJ0UnhIT0dHUXhYaG9oVTBEblUyRG14UzFabm5Lb3FDQ2pPYUtvdy1FS0JZS3Zzbkp4THo3cU1DVHpa
MUkzcVlhYnhQTGtwVHdabU9LYkI0OVVhOVNrY3pMNi1WUFg5blVBdjhETXRIUHdYbjdoSWlneEFlaTdz
bkpGWGo4ZWNlTmg5ZEdadl9rMGJPSzRYU0EycXFVeFI5WUxYREo4YmNMREt4eDd1a2NmTWVPdnVFZ09P
WXlhNDRMQlBDdktYejUzNk9xa1Rrak12ZDgtczFIMGs1QTM5ZDZPOWZfREY3RW5RRE9KRk9rX0Q3Rmgt
eGpXWm9qS2h4YXl5WU9YMkNXY2g0Z3lOQk1BajNOMFRUSEJPbTl1WEJNZHlOdFJfOG01alQyOXZobmlX
UGhOVGZ3Ym5ZSGVnWnhTbVBtV3FkR3h6T3pXaWhRWHhlUXlhd2dPOFVJdHcifX0.eyJ2YyI6eyJAY29u
dGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vcHVy
bC5pbXNnbG9iYWwub3JnL3NwZWMvb2IvdjNwMC9jb250ZXh0Lmpzb24iLCJodHRwczovL3B1cmwuaW1z
Z2xvYmFsLm9yZy9zcGVjL29iL3YzcDAvZXh0ZW5zaW9ucy5qc29uIl0sImlkIjoiaHR0cDovLzFlZHRl
Y2guZWR1L2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiT3Bl
bkJhZGdlQ3JlZGVudGlhbCJdLCJuYW1lIjoiMUVkVGVjaCBVbml2ZXJzaXR5IERlZ3JlZSBmb3IgRXhh
bXBsZSBTdHVkZW50IiwiZGVzY3JpcHRpb24iOiIxRWRUZWNoIFVuaXZlcnNpdHkgRGVncmVlIERlc2Ny
aXB0aW9uIiwiaW1hZ2UiOnsiaWQiOiJodHRwczovLzFlZHRlY2guZWR1L2NyZWRlbnRpYWxzLzM3MzIv
aW1hZ2UiLCJ0eXBlIjoiSW1hZ2UiLCJjYXB0aW9uIjoiMUVkVGVjaCBVbml2ZXJzaXR5IERlZ3JlZSBm
b3IgRXhhbXBsZSBTdHVkZW50In0sImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmV4YW1wbGU6
ZWJmZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIiwidHlwZSI6IkFjaGlldmVtZW50U3ViamVjdCIsImFj
dGl2aXR5RW5kRGF0ZSI6IjIwMTAtMDEtMDJUMDA6MDA6MDBaIiwiYWN0aXZpdHlTdGFydERhdGUiOiIy
MDEwLTAxLTAxVDAwOjAwOjAwWiIsImNyZWRpdHNFYXJuZWQiOjQyLCJsaWNlbnNlTnVtYmVyIjoiQS05
MzIwMDQxIiwicm9sZSI6Ik1ham9yIERvbW8iLCJzb3VyY2UiOnsiaWQiOiJodHRwczovL3NjaG9vbC5l
ZHUvaXNzdWVycy8yMDEyMzQiLCJ0eXBlIjoiUHJvZmlsZSIsIm5hbWUiOiIxRWRUZWNoIENvbGxlZ2Ug
b2YgQXJ0cyJ9LCJ0ZXJtIjoiRmFsbCIsImlkZW50aWZpZXIiOlt7InR5cGUiOiJJZGVudGl0eU9iamVj
dCIsImlkZW50aXR5SGFzaCI6InN0dWRlbnRAMWVkdGVjaC5lZHUiLCJpZGVudGl0eVR5cGUiOiJlbWFp
bEFkZHJlc3MiLCJoYXNoZWQiOmZhbHNlLCJzYWx0Ijoibm90LXVzZWQifSx7InR5cGUiOiJJZGVudGl0
eU9iamVjdCIsImlkZW50aXR5SGFzaCI6InNvbWVib2R5QGdtYWlsLmNvbSIsImlkZW50aXR5VHlwZSI6
ImVtYWlsQWRkcmVzcyIsImhhc2hlZCI6ZmFsc2UsInNhbHQiOiJub3QtdXNlZCJ9XSwiYWNoaWV2ZW1l
bnQiOnsiaWQiOiJodHRwczovLzFlZHRlY2guZWR1L2FjaGlldmVtZW50cy9kZWdyZWUiLCJ0eXBlIjoi
QWNoaWV2ZW1lbnQiLCJhbGlnbm1lbnQiOlt7InR5cGUiOiJBbGlnbm1lbnQiLCJ0YXJnZXRDb2RlIjoi
ZGVncmVlIiwidGFyZ2V0RGVzY3JpcHRpb24iOiIxRWRUZWNoIFVuaXZlcnNpdHkgRGVncmVlIHByb2dy
YW1zLiIsInRhcmdldE5hbWUiOiIxRWRUZWNoIFVuaXZlcnNpdHkgRGVncmVlIiwidGFyZ2V0RnJhbWV3
b3JrIjoiMUVkVGVjaCBVbml2ZXJzaXR5IFByb2dyYW0gYW5kIENvdXJzZSBDYXRhbG9nIiwidGFyZ2V0
VHlwZSI6IkNGSXRlbSIsInRhcmdldFVybCI6Imh0dHBzOi8vMWVkdGVjaC5lZHUvY2F0YWxvZy9kZWdy
ZWUifSx7InR5cGUiOiJBbGlnbm1lbnQiLCJ0YXJnZXRDb2RlIjoiZGVncmVlIiwidGFyZ2V0RGVzY3Jp
cHRpb24iOiIxRWRUZWNoIFVuaXZlcnNpdHkgRGVncmVlIHByb2dyYW1zLiIsInRhcmdldE5hbWUiOiIx
RWRUZWNoIFVuaXZlcnNpdHkgRGVncmVlIiwidGFyZ2V0RnJhbWV3b3JrIjoiMUVkVGVjaCBVbml2ZXJz
aXR5IFByb2dyYW0gYW5kIENvdXJzZSBDYXRhbG9nIiwidGFyZ2V0VHlwZSI6IkNUREwiLCJ0YXJnZXRV
cmwiOiJodHRwczovL2NyZWRlbnRpYWxlbmdpbmVyZWdpc3RyeS5vcmcvcmVzb3VyY2VzL2NlLTk4Y2Iw
MjdiLTk1ZWYtNDQ5NC05MDhkLTZmNzc5MGVjNmI2YiJ9XSwiYWNoaWV2ZW1lbnRUeXBlIjoiRGVncmVl
IiwiY3JlYXRvciI6eyJpZCI6Imh0dHBzOi8vMWVkdGVjaC5lZHUvaXNzdWVycy81NjUwNDkiLCJ0eXBl
IjoiUHJvZmlsZSIsIm5hbWUiOiIxRWRUZWNoIFVuaXZlcnNpdHkiLCJ1cmwiOiJodHRwczovLzFlZHRl
Y2guZWR1IiwicGhvbmUiOiIxLTIyMi0zMzMtNDQ0NCIsImRlc2NyaXB0aW9uIjoiMUVkVGVjaCBVbml2
ZXJzaXR5IHByb3ZpZGVzIG9ubGluZSBkZWdyZWUgcHJvZ3JhbXMuIiwiZW5kb3JzZW1lbnQiOlt7IkBj
b250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L2NyZWRlbnRpYWxzL3YxIiwiaHR0cHM6Ly9w
dXJsLmltc2dsb2JhbC5vcmcvc3BlYy9vYi92M3AwL2NvbnRleHQuanNvbiIsImh0dHBzOi8vdzNpZC5v
cmcvc2VjdXJpdHkvc3VpdGVzL2VkMjU1MTktMjAyMC92MSJdLCJpZCI6Imh0dHA6Ly8xZWR0ZWNoLmVk
dS9lbmRvcnNlbWVudGNyZWRlbnRpYWwvMzczMiIsInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwi
LCJFbmRvcnNlbWVudENyZWRlbnRpYWwiXSwiaXNzdWVyIjp7ImlkIjoiaHR0cHM6Ly9hY2NyZWRpdGVy
LmVkdS9pc3N1ZXJzLzU2NTA0OSIsInR5cGUiOiJQcm9maWxlIiwibmFtZSI6IkV4YW1wbGUgQWNjcmVk
aXRpbmcgQWdlbmN5In0sImlzc3VhbmNlRGF0ZSI6IjIwMTAtMDEtMDFUMDA6MDA6MDBaIiwiZXhwaXJh
dGlvbkRhdGUiOiIyMDIwLTAxLTAxVDAwOjAwOjAwWiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoi
aHR0cHM6Ly8xZWR0ZWNoLmVkdS9pc3N1ZXJzLzU2NTA0OSIsInR5cGUiOiJFbmRvcnNlbWVudFN1Ympl
Y

# data[].attributes.attachment_link.description
This specification is a new version of the 1EdTech Open Badges Specification that aligns with the conventions of the Verifiable Credentials Data Model v1.1 for the use cases of Defined Achievement Claim and a Skill Claim. The credentials that are produced are easily be bundled into Comprehensive Learner Records and Verifiable Presentations.

# data[].attributes.headline
Be BRIEF! Name, role, primary intersests. 

# data[].attributes.subject
Be BRIEF! Name, role, primary intersests. 

# data[].attributes.body
Phil Long/Consultant/AI agents

Phil's email: phil@rhzconsulting.com

# data[].attributes.body
Why A.I.? Is there a demo of where parsing engines are not working well enough? What is is the benchmark use case for 'well enough'? - Lloyd Fassett, from the zoom chat

# data[].attributes.body
Kinda curious how the AI might use a photo of a painting I’ve painted, to make visible my painting skills and experience? Are we thinking of photos as unstructured data? - Kelly Page, zoom chat

# data[].attributes.body
@Deb I’m deeply curious if you’ve prototyped an ai-based digestion model that turns input data (course program, pathways, credentials, etc) into the CTDL. - Robert Bajor, zoom chat

# data[].attributes.body
If folks are looking for open source ML tools for working with skills data that supports formats like CTDL, here’s a good one: https://github.com/workforce-data-initiative/skills-ml - Matt Gee, zoom chat

# data[].attributes.body
Do you have a collaborative research agreement to share? - Kathleen Webb, zoom chat

# data[].attributes.body
Ethical AI be interpreted differently in the US as opposed to the EU as opposed to…etc. - Elizabeth Wallace

# data[].attributes.body
AACRAO - QA Higher ED output

# data[].attributes.body
What kind of prototypes? -Kathleen Webb

# data[].attributes.body
Credential Engine, interested in CTDL, OB, meaningful human- and machine-actionable data empowering people!

# data[].attributes.body
Technical Program Manager for Digital Credentials, includes Open Badges 3.0 and Comprehensive Learner Record 2.0 standards.

# data[].attributes.body
Prompt to ChatPL: Reframe Experience You.

- RPL via AI
- Implementation of Open Recognition principles
- Hacking UNESCO Global Recognition Convention

# data[].attributes.body
Think about the millions of unstructured academic records that people already have - we would want to scale to this

# data[].attributes.body
Hyland Software - Verifiable Credentials Manager.

# data[].attributes.body
all open and publicly available for training data-- across credentials, courses, skills, etc.-- Credential Engine can provide API access and/or raw data sets

# data[].attributes.body
Head of Product - PAIRIN

# data[].attributes.headline
Andrew Cunsolo, Jobvite and HR Open Standards

# data[].attributes.subject
Andrew Cunsolo, Jobvite and HR Open Standards

# data[].attributes.body
Jobvite - Product Management of Recruitment Marketing and related partner integrations

HR Open Standards Consortium - Recruiting Workgroup Lead and Board of Directors - focusing on LER Resume Standards development to support evolution of VCs and skills-based hiring

# data[].attributes.body
My email is lloyd@bleblubla.com / based in Bend, Oregon / https://www.linkedin.com/in/frictionless/

I've been building a CTDL / JSON-LD for profit platform for Labor Marketplaces and expect to launch this spring.

We are not incorporating A.I. yet, but staging ourselves to.

This isn't live yet, but it will be here: https://bleblubla.com

# data[].attributes.attachment_link.description
750 million+ members | Manage your professional identity. Build and engage with your professional network. Access knowledge, insights and opportunities.

# data[].attributes.body
can we get historic, anonymous course and degree information for training and matching credentials with institutions?

# data[].attributes.body
AACRAO - Higher Ed

# data[].attributes.headline
Successful creation of a Verifiable Credential for the learner/earner.

# data[].attributes.subject
Successful creation of a Verifiable Credential for the learner/earner.

# data[].attributes.body
Open Badges 3.0 and CLR 2.0 are native verifiable credentials. If the standards are followed, they vc will be achieved.

# data[].attributes.body
Admission Officers accepting a Self-Attested XU credential for enrolment purpose

# data[].attributes.body
-QA of the output to insure accurate representation of the input.
-ensuring representation of achievements and supporting data within the data standards are consistent enough to ensure reliable interpretation of result.
-Enabling the transformation mechanism can be available at scale to both learners and issuers
Tracking authority associated with converted objects.

# data[].attributes.body
More directed towards support for the pilot staff for the pilot teams. This is phase 1. After this, we will seek a round 2 for the implementation of the prototypes

# data[].attributes.body
employers actually using these LERs in hiring processes and successfully finding talent matches (for hiring AND advancement)

# data[].attributes.body
Arizona State University

# data[].attributes.headline
Karen Kilroy - Author: Blockchain Tethered AI (O'Reilly, 2023)

# data[].attributes.subject
Karen Kilroy - Author: Blockchain Tethered AI (O'Reilly, 2023)

# data[].attributes.body
https://blockchaintetheredai.com

https://linkedin.com/in/karenkilroy

karen@kilroyblockchain.com

I have free open source code that accompanies my book that anyone is free to use to develop a workflow framework to capture and transfer experiment details like F1 score.

# data[].attributes.body
- Individual (candidate)
-  validation taht the AI created appropriate structured LER from their resume
- can import this VC in some sort of wallet or application
- individual can use VCs as part of a job application or other application

- Employers (or other consumer)
- validation that the LERs created match or represent the individual appropriately (manual review)
- can use or import a candidate LER as part of a job application or other application

# data[].attributes.body
Can data for assertion be verified, or will everything be a self-assertion? A combination of both would be ideal, in my personal opinion.

# data[].attributes.body
Wide variety and plethora of legacy credentials sufficient to prove the efficacy of the process.
Wide variety of reviewers to ensure to draw appropriate conclusions of the structured data.

# data[].attributes.body
https://www.imsglobal.org/spec/clr/v2p0/

# data[].attributes.attachment_link.readable_text
Candidate Final
Spec Version 2.0

Candidate Final

IPR and Distribution Notice

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.

1EdTech takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on 1EdTech's procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights webpage: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf .

The following participating organizations have made explicit license commitments to this specification:

Org name

Date election made

Necessary claims

Type

Use of this specification to develop products or services is governed by the license with 1EdTech found on the 1EdTech website: http://www.imsglobal.org/speclicense.html.

Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.

The limited permissions granted above are perpetual and will not be revoked by 1EdTech or its successors or assigns.

THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.

Public contributions, comments and questions can be posted here: http://www.imsglobal.org/forums/ims-glc-public-forums-and-resources .

Abstract

The Comprehensive Learner Record (CLR) Standard has been designed to create, transmit, and render an individual's set of achievements, as issued by multiple learning providers, in a machine-readable format that can be curated into verifiable digital records of achievement.

Table of Contents

1. Abstract

2. 1. Overview

3. 2. Use Cases

4. 3. Getting Started

5. 4. CLR Standard Document Formats
4.3 Image Format

1. 4.3.1 PNGs

2. 4.3.2 SVG

6. 5. CLR Standard API

7. 6. CLR Standard API Security

8. 7. Proofs (Signatures)
7.2 JSON Web Token Proof Format

9. 8. Verification and Validation

10. 9. Credential equality and comparison algorithm

11. 10. Verifiable Credentials Extensions

12. 11. Best Practices and Implementation

13. 12. Conformance and Certification Guide

14. A. Serialization

15. B. Data Models

1. B.4 Shared Credential Data Models

2. B.5 Shared API Security Data Models

3. B.6 Shared API Data Models

16. C. Extending and Profiling this Standard

17. D. Examples

18. E. Schema
E.2 JSON Schema
E.2.1 Comprehensive Learner Record Standard JSON Schema

19. F. OpenAPI Schema

20. G. Revision History

21. H. References

1. H.1 Normative references

2. H.2 Informative references

22. I. List of Contributors

This section is non-normative.

The target readers for this document are:

The CLR Standard (Comprehensive Learner Record Standard) has several related documents and artifacts shown below. Together they make up the specification.

The Open API Specification (OAS) defines a standard, programming language-agnostic interface description for HTTP APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic. When properly defined via OpenAPI, a consumer can understand and interact with the remote service with a minimal amount of implementation logic. Similar to what interface descriptions have done for lower-level programming, the OpenAPI Specification removes guesswork in calling a service.

-- OpenAPI Specification

When two people communicate with one another, the conversation takes place in a shared environment, typically called "the context of the conversation". This shared context allows the individuals to use shortcut terms, like the first name of a mutual friend, to communicate more quickly but without losing accuracy. A context in JSON-LD works in the same way. It allows two applications to use shortcut terms to communicate with one another more efficiently, but without losing accuracy.

Simply speaking, a context is used to map terms to IRIs. Terms are case sensitive and any valid string that is not a reserved JSON-LD keyword can be used as a term.

-- JSON-LD 1.1

The context file is available at: https://purl.imsglobal.org/spec/clr/v2p0/context.json.

All JSON Schema can be found in § E.2 JSON Schema. JSON Schema files for credentials and API schema verification are available online:

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, NOT RECOMMENDED, NOT REQUIRED, OPTIONAL, RECOMMENDED, REQUIRED, SHALL, SHALL NOT, SHOULD, and SHOULD NOT in this document are to be interpreted as described in [RFC2119].

An implementation of this specification that fails to implement a MUST/REQUIRED/SHALL requirement or fails to abide by a MUST NOT/SHALL NOT prohibition is considered nonconformant. SHOULD/SHOULD NOT/RECOMMENDED statements constitute a best practice. Ignoring a best practice does not violate conformance but a decision to disregard such guidance should be carefully considered. MAY/OPTIONAL statements indicate that implementers are entirely free to choose whether or not to implement the option.

The Conformance and Certification Guide for this specification may introduce greater normative constraints than those defined here for specific service or implementation categories.

Achievement Type: A vocabulary which describes the type of achievement.

Alignment: An alignment is a reference to an achievement definition, whether referenced in a resource outside the package or contained within the package.

Association: An association is the relationship between one assertion in a CLR has with another assertion in that CLR.

Claim: A statement about the Credential Subject. A claim may include associated evidence, results, or other metadata regarding a specific achievement, skill or assertion.

client: In a REST API, the client is the actor that initiates the DELETE, GET, or POST request. Also called a Consumer in the IMS Global Security Framework v1.1.

Comprehensive Learner Record (CLR): Set of assertions that can be packaged as a credential.

Credential: A set of one or more claims made by an issuer. 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. [VC-DATA-MODEL]

Decentralized Identifiers: A type of identifier for people, organizations and any other entity, where each identifier is controlled independently of centralized registries. [DID-CORE] [DID-USE-CASES]

Digital Credential Achievement (DC Achievement): This is the content description of a credential that an assertion references. It contains metadata such as the name of the achievement, description, alignment of skills, etc. An Open Badge asserts a single achievement. A CLR asserts a collection of assertions, each of which asserts a single achievement.

Digital Credential Assertion (DC Assertion): The core of both Open Badges and CLR is the assertion about achievement(s). DC Assertion properties are specific to one learner's achievement and specify metadata such as issuer, date of achievement, expiration data, as well as results and evidence that support the assertion. A Verifiable Credential more broadly asserts a claim about a Credential Subject which can be applied to education and occupational achievements.

Evidence: Information supporting a claim such as a URL to an artifact produced by the Learner.

Issuer: A role an entity can perform by asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential.

Learner: The person who is the subject of the CLR and assertions contained in a CLR.

Open Badge: A single assertion of an achievement that is packaged as a verifiable credential.

Presentation: Data derived from one or more verifiable credentials, issued by one or more [=issuers=, that is shared with a specific verifier. 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. [VC-DATA-MODEL]

Publisher: The organization or entity issuing the CLR (typically the educational institution or a 3rd-party agent). The publisher is either the issuer or has a trusted relationship with the issuer of all the assertions in the CLR.

Relying Third-Party: Also referred to as the "verifier" of a VC. This entity requests, verifies, and may consume data being presented.

REST API: A style of web API (Application Programming Interface) loosely based on HTTP methods (DELETE, GET, POST, and PUT) to access resources (e.g. CLRs) via a URL.

Result: Describes a possible achievement result. A result may contain the rubric level that was achieved.

Result Description: Describes a possible achievement result. A result description may contain a rubric.

Rubric: Defines levels associated with the achievement definition (e.g. "approaches", "meets", and "exceeds").

server: In a REST API, the server is the actor that responds to a DELETE, GET, or POST request. Also called a Platform in the IMS Global Security Framework v1.1.

Skill Assertion: An assertion that contains a "skill result."

Validation: The process of assuring the verifiable credential or verifiable presentation meets the needs of the verifier and other dependent stakeholders. Validating verifiable credentials or verifiable presentations is outside the scope of this specification.

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.

Verifier: The entity that receives a verifiable credential or verifiable presentation and verifies the credential or presentation has not been tampered with.

This conceptual model describes CLR concepts and the relationship between those concepts. The data model in appendix § B.4 Shared Credential Data Models below is the normative reference for the classes and properties that are used to implement the concepts.

The conceptual model is targeted for all § 1.1 Audiences, while the data model is targeted for Solution Architects and Product Developers.

In the diagram below, the concepts are shown in gray boxes (e.g. Associations). Please see § 1.4 Terminology for definitions of the concepts.

Starting with this version of the CLR Standard, a CLR is also a Verifiable Credential (VC) as defined by the Verifiable Credentials Data Model v1.1 specification. The diagram includes labels that show the relationships between VC terminology and CLR terminology (e.g. Publisher is identified by the VC "issuer").

I, Publisher assert a Claim about this Credential Subject
The claim provides the identity of the publisher, issuance date, and instructions on how to cryptographically prove the publisher identity and that the assertion and claim contents have not been tampered with since issuance.

The claim must describe a single credential subject which identifies the recipient of the CLR as the learner.

The claim must also contain a packaged set of assertions where each assertion is a DC Assertion with a definition shared by the [OB-30] and [CLR-20] standards. The issuer of each assertion may or may not be the same entity as the publisher. The recipient of each assertion must be the Learner even if the issuer uses a different identification for the learner. The publisher claims that this packaged set of assertions represents the publisher's complete CLR for the learner at the time of issuance.

The claim may also contain a packaged set of DC Achievements which the publisher claims to represent a complete set of achievements that may be asserted by issuers about the learner at some time in the future.

The claim may also contain Associations between assertions in the CLR.

This section is non-normative.
The use cases below drive the design of the CLR Standard v2.0.

The use cases are tagged with the following categories.

Higher Education

These use cases involve transcripts and proof of degrees, continuing and profession education, and co-curricular activities in higher education.

K12

These use cases involve transcripts and co-curricular activities in primary and secondary education.

Employment

These use cases involve employers, job applicants, and LERs (Learning and Employment Records).

Training Providers

These use cases involve community colleges, technical high schools, MOOC (Massive Open Online Course) providers, and training providers such as CompTIA (the Computing Technology Industry Association), CDL (Commerical Drivers License) training providers, and OSHA (Occupational Safety and Health Administration) training providers.

Licensing and Regulatory Affairs

These use cases involve licensing and regulatory affairs, and state or federal licensing boards such as CDL issuers, CNA (Certified Nursing Assistant) issuers, workforce development organization, candidate coaching organizations, and government licensure orgs.

Military

These use cases involve training provided by a military organization, and career services provided by the military such as MilGears.

Professional Organization

These use cases involve training provided by professional organizations such as trade associations including the National Trade Association, BBB (Better Business Bureau), and SAG-AFTRA (Screen Actors Guild - American Federation of Television and Radio Artists).

Categories: @@@TBD

As a working professional, Jane wants to advance her career by earning a credential that proves that she has obtained specific skills.

Jane is an employee at Local Company. To increase her chances of gaining a promotion at work, she would like to earn the Advanced Problem Solving Certificate at Georgia Tech Professional Education. This certificate requires completing a series of 4 in-person courses at Georgia Tech, each of which takes approximately 2-3 days. Upon completion, Jane would like to present a printed certificate to her employer as proof of completion. She would also like to add digital micro-credentials to her digital wallet for each of the 4 short courses, and a digital credential that represents her completion of the entire 4-course program. Eventually, Jane could share her digital credentials with her employer and they would automatically be ingested into Local Company's talent management system as part of Jane's employee record. These digital records would also be verifiable and tamper-proof. However, Local Company's current systems still necessitate the printable certificate.

Goal of the Primary Actor: Jane wants to earn an Advanced Problem Solving Certificate in order to advance her career.
Actors Preconditions for this Use Case Flow of Events

1. Jane completes course 1.

2. Upon completion of the in-person course, a GTPE employee marks Jane as complete in the GTPE learning management system.

3. The GTPE learning management system presents a deep link specific to Jane that allows her to claim the micro-credential for the course.

4. Jane imports the course 1 micro-credential into her wallet.

5. Repeat a-c for courses 2-4.

6. Upon completing 4 courses, the GTPE SIS issues the program certificate.

7. Jane is emailed a deep link that allows her to claim the program digital certificate.

8. Jane is also emailed a printable certificate (preferably in PDF format) with a unique serial number (or similar security).

9. Jane presents the printed certificate to her employer

10. Her employer manually records the certificate in Jane's employee record.

11. Using her digital wallet, and shares some or all of her five digital credentials with her online network and future potential employers.

(The following steps occur in a future state when Local Company's internal HR systems can ingest digital credentials)

1. Jane opens her digital wallet, and shares the program-level digital credential with her employer.

2. The employer verifies the credentials and ingests them into Jane's employee record.

3. When a promotion opportunity arises at Local Company, Jane is flagged as a qualified candidate due -- in part -- to her Advanced Problem Solving certificate.

Post-Conditions/Success Criteria Points of Failure

Categories: Employment

Sarah, a graduate of a teacher training program, wants to present my license and endorsements to a school district for potential employment.

Goal of the Primary Actor: Sarah wishes to teach Algebra I at Northwoods High School and prove her credentials are adequate.
Actors Preconditions for this Use Case Flow of events

1. University creates endorsement of candidate

2. Teacher applies for license

3. Teacher issued license

4. Teacher receives their license as a CLR VC with endorsements as assertions

5. District inspects the license

6. District inspects the degree

7. Teacher is placed in school

Post-Conditions/Success Criteria

Districts are able to quickly qualify eligible candidates

Districts have more access to licensed candidates directly matched to their job openings.

Points of Failure

As an ETS Praxis test taker I wish to share my test results as a VC with States for issuance of a license.

Goal of the Primary Actor: Judah wants to get his teaching license in Utah to teach 3rd grade in Granite School District. He has taken the Praxis test for Elementary Education and the test for School Leadership because he may apply for a principal position in the future.
Actors Preconditions for this Use Case Flow of events

1. Judah takes 2 Praxis tests and passes

2. Judah is issued a VC with the raw test results

3. State of Utah receives Judah's Praxis results

4. Judah meets all conditions and is issued a license.

5. GSD has an open position and requests a proof of Praxis score from Judah.

6. Judah shares the VC of his Praxis Report.

7. Judah employed by GSD

Post-Conditions/Success Criteria

Judah gets placed with a school district 3-6 months faster than current architecture.

no business requirements have to change to achieve this result, only technical.

Points of Failure
The school district cannot import Judah's credentials into their existing systems.

Categories: K12

Sammy is a student being tutored by Terry as part of a high intensity tutoring program.

Goal of the Primary Actor: Terry's goal is to record an observation of a performance level to one or more learning objective at the beginning and end of each tutoring session.
Preconditions for this Use Case

BCPS has published learning objectives with crosswalks to state standards in CASE.

BCPS has worked with tutoring providers to implement CLR publishing to a learning ledger captured by Microsoft's Open Education Architecture (OEA).

Flow of Events

1. Terry Tutor uses a Tutor Operations platform and the beginning and end of each session to record performance level associated with one or more learning objectives.

2. The Tutor Operations platform publishes an achievement assertion for each objective assessed to a Learning Ledger.

3. BCPS publishes learner profile views through secure LTI to Canvas LMS

4. BCPS packages and publishes sets of achievement assertions as Verifiable Credentials to parent/guardians and adult learners.

Post-Conditions/Success Criteria

Until they are 18, Sammy's parents are able to hold all requested achievement assertions on any compliant digital wallet and control requests for access and presentation of verifiable records.

Broward College is able to verifiable Sammy's records.

Points of Failure Variations

Terry is a teacher, not a tutor and is using a gradebook.

Sammy is administered a test by a 3rd party group.

This section is non-normative.

If you are new to CLR, please start here.

If you are migrating from CLR 1.0 [CLR-10] to CLR 2.0, please start here.

Version 1.0

Version 2.0

While based on Open Badges 2.0 [OB-20] concepts; the CLR and OB data models are not completely compatible and therefore require some translation.

Fully compatible with both the Open Badges 3.0 Data Model [OB-30] and the Verifiable Credentials 1.1 Data Model [VC-DATA-MODEL].

Hosted and Signed verification supported using [OB-20]-style Verficiation methods.

Verfication uses [VC-DATA-MODEL] Proof Methods.

ClrCredentials can be exchanged as documents as defined in this section, or using the CLR Standard API. Documents can be exchanged as a text file, as a web resource, or embedded in an image. The contents of a CLR document MUST meet the following criteria:

The contents of the CLR document MUST represent exactly one ClrCredential

The contents MUST be serialized as JSON and JSON-LD (see § A. Serialization)

JSON exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8 [RFC3629].

If the credential is signed using the § 7.2 JSON Web Token Proof Format (VC-JWT) the contents of the file MUST be the Compact JWS string formed as a result of signing the ClrCredential with VC-JWT. The file extension SHOULD be ".jws" or ".jwt".

If an embedded proof method is used instead, the contents of the file MUST be the JSON representation of the ClrCredential. The file extension SHOULD be ".json".

If the credential is signed using the § 7.2 JSON Web Token Proof Format (VC-JWT) the contents of the response MUST be the Compact JWS string formed as a result of signing the ClrCredential with VC-JWT. The Content-Type SHOULD be text/plain.

If an embedded proof method is used instead, the contents of the response MUST be the JSON representation of the ClrCredential. The Content-Type SHOULD be application/json or application/ld+json.

Comprehensive Learner Records (CLRs) may be exchanged as image files with CLRs encoded within. This allows CLRs to be portable wherever image files may be stored or displayed.

"Baking" is the process of taking a ClrCredential and embedding it into the image, so that when a user displays the image on a page, software that is CLR-aware can automatically extract that ClrCredential data and perform the checks necessary to see if a person legitimately earned the achievements within the CLR. The image must be in either [PNG] or [SVG] format in order to support baking.

CLRs can be exchanged using the API (application programming interface) defined here, or as documents.

This specification defines a RESTful API protocol to be implemented by applications serving in the roles of Client and Resource Server. The API uses OAuth 2.0 for authentication and granular resource-based permission scopes. Please see theComprehensive Learner Record Standard Conformance and Certification Guide v2.0 for a list of which endpoints must be implemented for certification.

Note : Non-individual access

The API defined here is intended for Clients and servers that give individual users control over access to their resources. While system-to-system bulk transfers using OAuth 2.0 Client-Credentials Grant are expected to occur, it is out of scope for this version of the specification to define. Future versions of this specification may add explicit support for OAuth 2.0 Client-Credentials Grant.

In addition to the documentation in this section, there are OpenAPI files for the CLR Standard API in both JSON and YAML format:

Figure 1 Diagram showing the major components of the Open Badges API

There are five key components to the API architecture.

User

This is the user that owns the resources (ClrCredentials) that are on the resource server. Also called a Resource Owner.

Web Browser

This is the web browser the user interacts with.

Client

This is the web application that interacts with the resource server on behalf of the user. Also called Consumer in theIMS Global Security Framework v1.1.

Authorization Server

This is a server that implements the OAuth 2.0 endpoints on behalf of theresource server. In many systems, the authorization server and the resource server are combined.

Resource Server

This is the server that has the protected resources (ClrCredentials). Also called Provider in the IMS Global Security Framework v1.1.

The role of each component during Registration, Obtaining Tokens, and Authenticating with Tokens are described below.

These endpoints are used to exchange ClrCredentials and Profile information.

All secure endpoint requests MUST be made over secure TLS 1.2 or 1.3 protocol.

All of the Secure REST Endpoints are protected by OAuth 2.0 access tokens as described in § 6. CLR Standard API Security.

Scopes

Each endpoint requires an access token with a specific CLR Standard scope as shown below.

Operation

Scope

getCredentials
https://purl.imsglobal.org/spec/clr/v2p0/scope/credential.readonly - Permission to read ClrCredentials for the authenticated entity.

upsertCredential
https://purl.imsglobal.org/spec/clr/v2p0/scope/credential.create - Permission to create or update ClrCredentials for the authenticated entity.

getProfile
https://purl.imsglobal.org/spec/clr/v2p0/scope/profile.readonly - Permission to read the profile for the authenticated entity.

putProfile
https://purl.imsglobal.org/spec/clr/v2p0/scope/profile.update - Permission to update the profile for the authenticated entity.

Get issued ClrCredentials from the resource server for the supplied parameters and access token.

Request
GET /ims/clr/v2p0/credentials?limit={limit}&offset={offset}&since={since}

limit
PositiveInteger
The maximum number of ClrCredentials to return per page.

Optional

offset
NonNegativeInteger
The index of the first ClrCredential to return. (zero indexed)

Optional

since
DateTime
Only include ClrCredentials issued after this timestamp.

Optional

Responses

GET /ims/clr/v2p0/credentials?limit=2&offset=0 Host : example.edu Authorization : Bearer 863DF0B10F5D432EB2933C2A37CD3135A7BB7B07A68F65D92 Accept : application/json

Create or replace a ClrCredential on the resource server, appending it to the list of credentials for the subject, or replacing an existing entry in that list. The resource server SHOULD use the credential equality and comparison algorithm to compare and determine initial equality. The response code makes clear whether the operation resulted in a replacement or an insertion.

Request
POST /ims/clr/v2p0/credentials

application/json
ClrCredential
If the ClrCredential is not signed with the VC-JWT Proof Format, the request body MUST be a ClrCredential and the Content-Type MUST be application/json.

Required

text/plain
CompactJws
If the ClrCredential is signed with the VC-JWT Proof Format, the request body MUST be a CompactJws string and the Content-Type MUST be text/plain.

Required

Responses

 200 OK Content-Type : application/json { "@context": [ "https://www.w3.org/2018/credentials/v1", "https://purl.imsglobal.org/spec/clr/v2p0/context.json", "https://purl.imsglobal.org/spec/ob/v3p0/context.json", "https://w3id.org/security/suites/ed25519-2020/v1" ], "id": "http://example.edu/credentials/3732", "type": [ "VerifiableCredential", "ClrCredential" ], "issuer": { "id": "https://example.edu/issuers/565049", "name": "Example University" }, "issuanceDate": "2010-01-01T00:00:00Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "verifiableCredential": [ { "@context": [ "https://www.w3.org/2018/credentials/v1", "https://purl.imsglobal.org/spec/ob/v3p0/context.json", "https://w3id.org/security/suites/ed25519-2020/v1" ], "id": "urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002", "type": [ "VerifiableCredential", "AchievementCredential" ], "issuer": { "id": "https://example.edu/issuers/565049", "type": "Publisher", "name": "Example University" }, "issuanceDate": "2010-01-01T00:00:00Z", "achievement": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21" }, "credentialSchema": [ { "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_clrcredential_schema.json", "type": "1EdTechJsonSchemaValidator2019" } ], "proof": { "type": "Ed25519Signature2020", "created": "2022-04-07T21:25:44Z", "verificationMethod": "did:key:undefined", "proofPurpose": "assertionMethod", "proofValue": "z2MVFHXZ8YK32d9zUfFk9hJsVNfdg3vDJsxSRqKpdaJ9T8WLAg1NcTHB91tfJrfDFkLBKtrRQFjqGkeTF3yqcz8ut" } } ], "achievement": [ { "id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002", "creator": { "id": "https://example.edu/issuers/565049" }, "name": "Achievement 1", "description": "Achievement 1", "image": { "id": "https://example.edu/achievements/sample.png" } }, { "id": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002", "creator": { "id": "https://example.edu/issuers/565049" }, "name": "Achievement 2", "description": "Achievement 2", "image": { "id": "https://example.edu/achievements/sample.png" } } ], "association": [ { "associationType": "isParentOf", "sourceId": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002", "targetId": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002" } ] }, "credentialSchema": [ { "id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_achievementcredential_schema.json", "type": "1EdTechJsonSchemaValidator2019" } ], "proof": { "type": "Ed25519Signature2020", "created": "2022-04-07T21:25:44Z", "verificationMethod": "did:key:undefined", "proofPurpose": "assertionMethod", "proofValue": "zMkGPxkm3cxzEAxbjTW9MWyQEM6WZNigeoGpqA2MZhPFqotVnin6oBJSya8hqwqcFRCWMHPedDUKrn31VQGgE9BF" } }

Fetch the profile from the resource server for the supplied access token. Profiles that are received MAY contain attributes that a Host SHOULD authenticate before using in practice.

Request
GET /ims/clr/v2p0/profile
Responses

GET /ims/clr/v2p0/profile Host : example.edu Authorization : Bearer 863DF0B10F5D432EB2933C2A37CD3135A7BB7B07A68F65D92 Accept : application/json

 200 OK Content-Type : application/json { "@context": [ "https://purl.imsglobal.org/spec/ob/v3p0/context.json", ], "type": "Profile", "id": "https://example.edu/issuers/565049", "name": "Example University" }

Update the profile for the authenticate entity.

Request
PUT /ims/clr/v2p0/profile

application/json
Profile
The request MUST include the entire Profile object. The resource server MAY respond with 400 BAD_REQUEST to reject data that is known immediately to not be acceptable by the platform, e.g. to reject a "telephone" property if the resource server cannot validate telephone numbers.

Required

Responses

PUT /ims/clr/v2p0/profile Host : example.edu Authorization : Bearer 863DF0B10F5D432EB2933C2A37CD3135A7BB7B07A68F65D92 Accept : application/json Content-Type : application/json { "@context": [ "https://purl.imsglobal.org/spec/ob/v3p0/context.json", ], "type": "Profile", "id": "https://example.edu/issuers/565049", "name": "Example University", "phone": "111-222-3333" }

Access to the discovery endpoint MUST NOT be protected. The Service Description Document (SDD) MUST be provided over HTTPS with TLS 1.2 or 1.3.

Fetch the Service Description Document from the resource server.

Request
GET /ims/clr/v2p0/discovery
Responses

 200 OK Content-Type : application/json ... "components": { "securitySchemes": { "OAuth2ACG": { "type": "oauth2", "description": "OAuth 2.0 Authorization Code Grant authorization", "x-imssf-name": "Example Provider", "x-imssf-privacyPolicyUrl": "provider.example.com/privacy", "x-imssf-registrationUrl": "provider.example.com/registration", "x-imssf-termsOfServiceUrl": "provider.example.com/terms", "flows": { "authorizationCode": { "tokenUrl": "provider.example.com/token", "authorizationUrl": "provider.example.com/authorize", "refreshUrl": "provider.example.com/token", "scopes": { "https://purl.imsglobal.org/spec/clr/v2p0/scope/delete" : "...", "https://purl.imsglobal.org/spec/clr/v2p0/scope/readonly" : "...", "https://purl.imsglobal.org/spec/clr/v2p0/scope/replace" : "..." } } } } }, "schemas": { ... } } ...

Pagination of getCredentials results is controlled by two query string parameters appended to the request. The response includes the following pagination headers.

Response Header

Description

Required

X-Total-Count: <total_count>
The resource server MUST include an X-Total-Count response header if the total result count is known. If the total result count is not known, the total count header MUST be ommitted.

Conditionally Required for 200 OK Response

Link: <pagination_links>
The resource server MUST include aLink response header if the list of credentials in the response is incomplete; and MAY include the Link header if the response is complete.

Conditionally Required for 200 OK Response

If present, the Link header MUST support all of the following link relations ( rel values):

Relation

Description

next

The link relation for the immediate next page of results. This MUST appear when the current list response is incomplete.

last

The link relation for the last page of results. This MUST always appear.

first

The link relation for the first page of results. This MUST always appear.

prev

The link relation for the immediate previous page of results. This MUST appear when the offset is greater than zero.

Resource Servers MAY implement a Retry-After header to indicate a period of time to wait before attempting the request again.

If no Retry-After header is present and the response is non-2XX, it is recommended to retry the request in 30 minutes for an additional two attempts. After which, it MAY be desirable to alert the user that there is an issue with the connection (e.g. perhaps they need to reauthenticate or manually trigger the request when they believe services are back up).

The CLR Stardard API endpoints must use the methods outlined in Section 4, "Securing Web Services" of the IMS Global Security Framework v1.1. Clients and servers that give individual users control over access to their resources MUST use the OAuth 2.0 Authorization Code Grant method. A partial list of examples are shown in the table below:

Example

Grant Method to Use

A university system maintains an achievement hub that students and alumni can use to retrieve their personal extended transcript. One of the students is using a digital wallet to assemble a personal portfolio. The student uses the wallet application to get their extended transcript from the university system's achievement hub. The client is the wallet application and the server is the achievement hub.

OAuth 2.0 Authorization Code Grant because the learner is accessing their own individual resources.

A learner has used a digital wallet to assemble a comprehensive record of their achievements. The learner uses the wallet application to "submit" their CLR to a potential employer. The client is the wallet application and the server is the employer's career tracking system.

Note : Non-individual access

The API defined here is intended for Clients and servers that give individual users control over access to their resources. While system-to-system bulk transfers using OAuth 2.0 Client-Credentials Grant are expected to occur, it is out of scope for this version of the specification to define. Future versions of this specification may add explicit support for OAuth 2.0 Client-Credentials Grant.

In scenarios where the learner or another third party is the resource owner, there will not be a pre-established trust relationship. Therefore the client credentials approach is insufficient. Instead you MUST use of OAuth 2.0 Authorization Code Grant.

Making a secured CLR Standard API request using authorization code grant comprises three steps:

1. § 6.1.1 ACG - Registration - Share configuration information between the client and the server.

2. § 6.1.2 ACG - Obtaining Tokens - Obtain an authorization code using a choreography between the client, web browser, user, and authorization server. Then request an access token by sending a request, using the previously obtained authorization code, to the Access Token service endpoint.

3. § 6.1.3 ACG - Authenticating with Tokens - Use the access token in the Authorization header of the API request

To get started, the client and authorization server must share the four pieces of information shown below. Clients and servers that implement the Authorization Code Grant (ACG) method of resource access MUST implement § 6.4 Dynamic Client Registration to share this information.

client_id

This is the public identifier for the communication exchange. Also called a Secret in the IMS Global Security Framework v1.1.

client_secret>

This is the shared secret for the communication exchange. Also called a Secret in the IMS Global Security Framework v1.1.

List of Scopes

The list of scopes that identify the set of endpoints for which access permission is being requested.

OAuth 2.0 Access Token Service Endpoint

The endpoint from which the approved, requesting client can obtain an access token.

If the client and authorization server support Token Revocation, they should also share:

OAuth 2.0 Revocation Service Endpoint

The endpoint a client can use to revoke an access token.

Figure 2 Sequence diagram for obtaining access tokens when using the ACG flow

Obtaining an access token using an authorization code has two steps:

Once obtained, the client can freely re-use the access token up until the token's expiry time, so that the client need not repeat steps of obtaining an authorization code and requesting an access token for every API request. Token refresh is also available (see § Token Refresh Request).

ACG - Authorization Request

After the client application is registered with the authorization server as described in § 6.4 Dynamic Client Registration, the client application then MAY initiate an authorization request as described in Section 4.2 of theIMS Global Security Framework v1.1 by redirecting the user to the authorizationUrl as declared in the resource server's Service Description Document (SDD).

In the OAuth 2.0 Security Best Practices document [OAUTH2-SBP] the use of Proof Key for Code Exchange (PKCE) [RFC7636] is recommended in order to (with the help of the authorization server) detect and prevent attempts to inject (replay) authorization codes into the authorization response. When using 1EdTech specifications, PKCE MUST be used to protect Authorization Code Grant based access. The PKCE has two stages:

First the client MUST supply a code_challenge andcode_challenge_method in the request for an authorization code. Theauthorization server is responsible for associating thecode_challenge with the issued authorization code.

Then the client MUST supply the code_verifier in the Access Token Request, and theauthorization server verifies the code_verifier.

client_id String
The client application identifier. MUST be the client_id provided in the Dynamic Client Registration § Register with Authorization Server response.

Required

redirect_uri URL
The client application's redirection endpoint. MUST match one of the redirect_uris in the § 6.1.1 ACG - Registration request. Although this is optional in theIMS Global Security Framework v1.1, it is REQUIRED by this specification.

Required

scope String
The scope of the authorization request. The authorization server is responsible for validating the scopes identified in the request and the response MUST include a scope parameter which confirms this list or comprises a subset of the services requested.

Required

state String
An opaque value used by the client application to maintain state between the request and callback. The authorization server includes this value when redirecting the web browser back to the client. This parameter MUST be used for preventing cross-site request forgery.

Required

All of the authorization request parameters are encoded in the authorization request as query string parameters. The request MUST be made by redirecting the browser to the OAuth 2.0 Authorization endpoint. The request MUST use HTTPS with TLS 1.2 or 1.3 protocol.

ACG - Authorization Response

If the redirect_uri matches a known client_id, the authorization server SHOULD present a UI asking the user to authenticate themself and grant the access request. The authorization server SHOULD display the client_name, client_uri, logo_uri, tos_uri, and policy_uri collected during Dynamic Client Registration to the user to help them decide whether to grant the access request.

If the user authorizes the client application to access their resources with the requested scopes, the authorization server MUST redirect the browser back to the redirect_uri with the code, scope, and state query string parameters.

The Authorization Code MUST be used only once. A lifetime for the authorization code of 600 seconds (10 minutes) is RECOMMENDED. If an authorization code is used more than once, the authorization server MUST deny the request and SHOULD revoke (when possible) all tokens previously issued based on that authorization code. The authorization code is bound to the client identifier and redirection URI.

scope
String
The authorized scope for the access request (this MAY be a subset of the scopes in the request). The value is a space delimited set of scopes.

Required

state
String
The opaque value supplied by the client to maintain state between the request and callback.

Required

Authorization Error Response

If the authorization server does not recognize the client applications's redirection endpoint from a prior connection with this client application, the authorization server SHOULD inform the user of the error and MUST NOT automatically redirect to the web browser to the invalid redirection URI.

If the user denies the authorization request or if the request fails for reasons other than a missing or invalid redirection URI, the authorization server informs the client by adding the following parameters to the query component of the redirection URI.

error AuthorizationError
A single ASCII [RFC20] error code from the AuthorizationError vocabulary.

Required

error_description String
Human-readable ASCII [RFC20] text providing additional information, used to assist the client developer in understanding the error that occurred. Values for the "error_description" parameter MUST NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E.

error_uri URI
A URI identifying a human-readable web page with information about the error, used to provide the client developer with additional information about the error. Values for the "error_uri" parameter MUST conform to the URI-reference syntax and thus MUST NOT include characters outside the set %x21 / %x23-5B / %x5D-7E.

 302 Found Location : https://client.example.com/cb?error=access_denied&state=xyz

ACG - Access Token Request

With the supplied code, the client application SHOULD attempt to exchange the code for an access_token. The client application makes an authorization grant POST request to the tokenUrl as declared in the resource server's Discovery Document. The HTTP POST request MUST include a Basic authorization header with the client_id and client_secret provided in the registration response. The body of the token request MUST include the following form fields:

ACG - Access Token Response

If the authorization server grants this request (see Section 5.1 in [RFC6749] for the detailed description), it returns HTTP 200 OK status code with content type "application/json" consisting of a JSON object containing the access token and its expiry lifetime (1EdTech recommends a default expiry lifetime of 3600 seconds, one hour, for access tokens), optionally a refresh token, and confirms the set of scopes supported by the access token:

Access Token Error Response

The authorization server MAY decide not to issue an access token. This could be because the request scopes are invalid, the credentials from the client may be invalid, etc. In this case the authorization server MUST return an HTTP 400 Bad Request status code with content type "application/json" consisting of a JSON object describing the error in the response body. The properties used to describe the error are:

error TokenError
A single ASCII [RFC20] error code]. See Section 5.2 of [RFC6749].

Required

error_uri URI
A URI identifying a human-readable web page with information about the error, used to provide the client developer with additional information about the error. Values for the "error_uri" parameter MUST conform to the URI-reference syntax and thus MUST NOT include characters outside the set %x21 / %x23-5B / %x5D-7E.

Optional

After obtaining an access_token and optionally a refresh_token using the method above, a client application MAY issue request that access resources controlled by the user on the resource server using the access_token in the HTTP Authorization header [RFC2617] with a Bearer Token [RFC6750]. For example, a "getCredentials" would look like this:

The recommended value of the access token's expires_in attribute is 3600 i.e. one hour. This means that the validity of the access token expires one hour after the time it was issued.

When requesting an access token as part of the Authorization Code Grant process, an authorization server MAY return a 'Refresh Token'. The refresh token can be used to obtain an access token using the same authorization grant: this is described in Section 6 of [RFC6749]. The use of the Refresh Token avoids the choreography for obtaining the credentials to gain access to the authorization server.

An Authorization Server is NOT REQUIRED to support token refresh.

Token Refresh Request

If the access_token is expired or about to expire, and the client application received a refresh_token, the client application can use OAuth 2.0 Token Refresh to get a new access_token and refresh_token.

The client makes a refresh POST request to the token endpoint by adding the following parameters using the "application/x-www-form-urlencoded" format in the HTTP request entity-body:

grant_type String
Value MUST be set to "refresh_token".

Required

scope String
The scope of the access request. The requested scope MUST NOT include any scope not originally granted by the user, and if omitted is treated as equal to the scope originally granted by the user.

Required

POST /token Host : auth.example.com Authorization : Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type : application/x-www-form-urlencoded grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA&scope=https%3A%2F%2Fpurl.imsglobal.org%2Fspec%2Fclr%2Fv2p0%2Fscope%2readonly

Token Refresh Response

If valid and authorized, the authorization server issues a new access token and optionally a new refresh token as described earlier in § ACG - Access Token Response. If the request failed verification or is invalid, the authorization server returns an error response as described earlier in § Access Token Error Response.

There may be deployments in which revocation of an access token is useful. The Token Revocation process is based upon [RFC7009]. The client requests the revocation of a particular token by making an HTTP POST request (using TLS) to the token revocation endpoint URL. Note that [RFC7009] states that implementations MUST support the revocation of refresh tokens and SHOULD support the revocation of access tokens.

Token Revocation Request

The client constructs the request by including the following parameters using the "application/x-www-form-urlencoded" format in the HTTP request entity-body:

token_type_hint String
MUST be set to either "access_token" or "refresh_token".

Required

POST /revoke Host : server.example.com Authorization : Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type : application/x-www-form-urlencoded token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token

Token Revocation Response

The authorization server responds with HTTP 200 OK status code if the token has been revoked successfully or if the client submitted an invalid token.

When the request for revocation is rejected, the authorization server returns an error response as described earlier in § Access Token Error Response with an error code of "unsupported_token_type".

Clients and servers that implement the Authentication Code Grant (ACG) method of resource access MUST implement the OAuth 2.0 Dynamic Client Registration Protocol [RFC7591]. There are two steps in this process:

1. Request the Service Description Document (SDD) from the resource server

2. Register with the authorization server

Figure 3 Sequence diagram for dynamic client registration when using ACG flow

The client only needs to register a client_id with the authorization server once. Each user will use the same client_id when they request their own authorization code.

Request the Service Description Document

To start the registration process, the user supplies the client with the resource server's base URL. When presented with an unknown resource server the client MUST request the resource server's Service Description Document (SDD) as shown in § 5.3.1 getServiceDescription.

Upon receiving a SDD from a resource server, the client SHOULD respect the Cache-Control and Expires headers if present in the response and configure local cache to match the directives it declares. If directives include one of no-cache, no-store, the client SHOULD NOT cache the data for future interactions. If directives include max-age or if an Expires header is present, the client SHOULD cache the SDD data, if valid, up to the expiration indicated, either at the time indicated by the Expires header or max-age seconds from request time.

An Etag header MAY be offered with the SDD response. If so, after a resource's declared expiration, a client MAY include an If-None-Match header containing the value of the Etag to check if the resource is still fresh. If so the resource server may return a 304 Not Modified response status code, and a new Expires or Cache-Control header MAY be included, which the client SHOULD use to update the cache expiration.

Register with Authorization Server

With the Client Registration URL in hand (from the x-imssf-registrationUrl property of the SDD), the client SHOULD post a registration request to the authorization server. The registration request MUST comply with OAuth 2.0 Dynamic Client Registration Protocol [RFC7591]. The registration request MUST NOT require an Initial Access Token. Use of the 'Software Statement' is NOT RECOMMENDED. The client registration request is sent to the Client Registration URL. The request MUST be sent using HTTPS with TLS 1.2 or 1.3 protocol.

The properties of the JSON body MUST be implemented as described in the following table. All URLs MUST use HTTPS (e.g. https://example.com/logo.png) and all URLs MUST have the same hostname. All required properties MUST be present in the registration request in order for it to be accepted by the authorization server. Arrays MUST be used even when a single value is to be sent.

logo_uri URL
The logo of the client application. If present, the authorization server SHOULD display this image to the end-user during approval. The value of this field MUST point to a valid image file.

Required

tos_uri URL
The human-readable Terms of Service for the client application that describes a contractural relationship between the end-user and the client that the end-user accepts when authorizing the client.

Required

software_id String
A unique idenfitier assigned by the client application developer or software published used by registration endpoints to identify the client application to be dynamically registered. As described in [rfc7591], it SHOULD remain the same for all instances of the client application software.

Required

software_version String
A version identifier string for the client application software identifies by software_id. The value of software_version SHOULD change on any update to the client application software identified by the same software_id.

Required

scope String
In the registration request, this is a string containing a space-separated list of scope values that this client application may include when requesting access tokens. If omitted, the authorization server MAY register a client application with a default set of scopes. In the registration response, this is a list of scopes the authorization server supports.

The list of scopes that can be requested are shown below:

https://purl.imsglobal.org/spec/clr/v2p0/scope/delete

Permission to delete CLRs for the user on the resource server platform.

https://purl.imsglobal.org/spec/clr/v2p0/scope/readonly

Permission to read CLRs for the user on the resource server platform.

https://purl.imsglobal.org/spec/clr/v2p0/scope/replace

Permission to create or update CLRs for the user on the resource server platform.

offline_access

Permission to issue a refresh_token along with theaccess_token.

Required

token_endpoint_auth_method String
String indicator of the requested authentication method for the token endpoint. In this specification only "client_secret_basic" is allowed:

"client_secret_basic": The client application uses the HTTP Basic authentication method as defined in OAuth 2.0.

If omitted, the default is "client_secret_basic".
Optional

grant_types String[]
Array of OAuth 2.0 grant type strings. In this specification only "authorization_code" and refresh_token" are allowed:

"authorization_code": The authorization code grant type defined in OAuth 2.0.

"refresh_token": The refresh token grant type defined in OAuth 2.0.

If omitted, the default behavior is that the client will use only the "authorization_code" grant type.
Optional

response_types String[]
Array of OAuth 2.0 response type strings. In this specification only "code" is allowed:

"code": The authorization code response type defined in OAuth 2.0.

If omitted, the default is that the client will use only the "code" response type.
Optional

contacts String[]
Array of strings representing ways to contact people responsible for this client, typically email addresses. The authorization server MAY make these contact addresses available to end-users for support requests for the client application. Privacy constraints MUST be supported as applicable.

Optional

POST /connect/register Host : auth.example.com Accept : application/json Content-Type : application/json; charset=utf-8 { "client_name": "Example Client Application", "client_uri": "https://client.example.com/", "logo_uri": "https://client.example.com/logo.png", "tos_uri": "https://client.example.com/terms", "policy_uri": "https://client.example.com/privacy", "software_id": "c88b6ed8-269e-448e-99be-7e2ff47167d1", "software_version": "v4.0.30319", "redirect_uris": [ "https://client.example.com/Authorize" ], "token_endpoint_auth_method": "client_secret_basic", "grant_types": [ "authorization_code", "refresh_token" ], "response_types": [ "code" ], "scope": "https://purl.imsglobal.org/spec/clr/v2p0/scope/delete https://purl.imsglobal.org/spec/clr/v2p0/scope/readonly https://purl.imsglobal.org/spec/clr/v2p0/scope/replace offline_access" }

If the authorization server accepts the registration request, it will store the information provided in the request and respond HTTP 201 Created with a registration response that includes a set of client credentials for the client application to use when requesting access tokens. All the information provided by the client application MUST be returned to the client application, including modifications to the properties as the authorization server deems necessary. An example response looks like this:

 201 Created Content-Type : application/json; charset=utf-8 { "client_id": "4ad36680810420ed", "client_secret": "af7aa0d679778e12", "client_id_issued_at": 1565715850, "client_secret_expires_at": 1597338250, "client_name": "Example Client Application", "client_uri": "https://client.example.com/", "logo_uri": "https://client.example.com/logo.png", "tos_uri": "https://client.example.com/terms", "policy_uri": "https://client.example.com/privacy", "software_id": "c88b6ed8-269e-448e-99be-7e2ff47167d1", "software_version": "v4.0.30319", "redirect_uris": [ "https://client.example.com/Authorize" ], "token_endpoint_auth_method": "client_secret_basic", "grant_types": [ "authorization_code", "refresh_token" ], "response_types": [ "code" ], "scope": "https://purl.imsglobal.org/spec/clr/v2p0/scope/delete https://purl.imsglobal.org/spec/clr/v2p0/scope/readonly https://purl.imsglobal.org/spec/clr/v2p0/scope/replace offline_access" }

The following table describes the properties present in the client registration response that were not included in the request. These are all REQUIRED properties.

client_id String
An OAuth 2.0 client identifier string. The value SHOULD NOT be currently valid for any other registered client.

Required

client_secret_expires_at
NonNegativeInteger

The time at which the client_secret will expire. MAY be 0 for no expiration. The time is represented as the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time of expiration.

Required

When a registration error condition occurs, the authorization server returns an HTTP 400 status code (unless otherwise specified) with content type "application/json" consisting of a JSON object describing the error in the response body. The properties used are:

This section describes mechanisms for ensuring the authenticity and integrity of CLR Standard documents and payloads. At least one proof mechanism, and the details necessary to evaluate that proof, MUST be expressed for a credential to be a verifiable credential; that is, to be verifiable.

The proof formats included in this specification fall into two categories:

JSON Web Token Proof - Somtimes called VC-JWT, this format has a single implementation: the credential is encoded into a JWT which is then signed and encoded as a JWS. The JSON Web Token proof is called an external proof because the proof wraps the credential object.

Linked Data Proofs - The credential is signed and the signature is used to form a Proof object which is appended to the credential. This format supports many different proof types. These are called embedded proofs because the proof is embedded in the data.

A third category of proof format called Non-Signature Proof is not covered by this specification. This category includes proofs such as proof of work.

This proof format relies on the well established JWT (JSON Web Token) [RFC7519] and JWS (JSON Web Signature) [RFC7515] specifications. A JSON Web Token Proof is a JWT signed and encoded as a Compact JWS string. The proof format is described in detail in Section 6.3.1 "JSON Web Token" of Verifiable Credentials Data Model v1.1. That description allows several options which may inhibit interoperability. This specification limits the options while maintaining compatibility with [VC-DATA-MODEL] to help ensure interoperability.

Some of the terms used in this section include:

JWT - "JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted." [RFC7519]

JWS - "JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification." [RFC7515]

JWK - "A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key." [RFC7517]

Compact JWS - "A compact representation of a JWS." [RFC7515]

A JWS is a signed JWT with three parts separated by period (".") characters. Each part contains a base64url-encoded value.

- Describes the cryptographic operations applied to the JWT and optionally, additional properties of the JWT. [RFC7515]

JWT Payload - The JSON object that will be signed. In this specification, the JWT Payload includes the ClrCredential.

JWS Signature - The computed signature of the JWT Payload.

The JOSE Header, JWT Payload, and JWS Signature are combined to form a Compact JWS. To transform a credential into a Compact JWS takes 4 steps:

1. Create the , specifying the signing algorithm to use

2. Create the JWT Payload from the credential to be signed

3. Compute the signature of the JWT Payload

4. Encode the resulting JWS as a Compact JWS

The resulting JWS proves that the issuer signed the JWT Payload turning the credential into a verifiable credential.

When using the JSON Web Token Proof Format, the proof property MAY be ommitted from the ClrCredential. If a Linked Data Proof is also provided, it MUST be created before the JSON Web Token Proof Format is created.

If you are going to use both external and embedded proof formats, add the embedded proofs prior to creating the JWT Payload.

1. Create a JSON object using the ClrCredentialJwtPayload data model.

2. Copy all of the claims from the parent credential to the new JSON object except for the nested credentials.

3. Process each nested credential:

If the nested credential is already signed with a JSON Web Token Proof, simply add the Compact JWS string to the new JSON object.

If the nested credential is not signed with a JSON Web Token Proof, sign it with a JSON Web Token Proof and add the resulting Compact JWS string to the new JSON object.

4. Use the new JSON object to form the JWT Payload.

exp NumericDate
The expirationDate property of the ClrCredential. Required if the ClrCredential has an expirationDate.

Optional

This section uses the follow notations:

JOSE Header - denotes the JSON string representation of the JOSE Header.

JWT Payload - denotes the JSON string representation of the JWT Payload.

BASE64URL(OCTETS) - denotes the base64url encoding of OCTETS per [RFC7515].

UTF8(STRING) - denotes the octets of the UTF-8 [RFC3629] representation of STRING, where STRING is a sequence of Unicode [UNICODE] characters.

The concatenation of two values A and B is denoted as A || B.

The steps to sign and encode the credential as a Compact JWS are shown below:

1. Encode the JOSE Header as BASE64URL(UTF8(JOSE Header)).

2. Encode the JWT Payload as BASE64URL(JWT Payload).

3. Concatenate the encoded JOSE Header and the encoded JSW Payload as A | "." | B.

4. Calculate the JWS Signature for C as described in [RFC7515].

5. Encode the signature as BASE64URL(JWS Signature).

6. Concatenate C and E as C | "." | E.

The resulting string is the Compact JWS representation of the credential. The Compact JWS includes the credential AND acts as the proof for the credential.

Verifiers that receive a ClrCredential in Compact JWS format MUST perform the following steps to verify the embedded credential.

1. Base64url-decode the JOSE Header.

2. If the header includes a kid property, Dereference the kid value to retrieve the public key JWK.

3. If the header includes a jwk property, convert the jwk value into the public key JWK.

4. Use the public key JWK to verify the signature as described in "Section 5.2 Message Signature or MAC Validation" of [RFC7515]. If the signature is not valid, the credential proof is not valid.

Note : Verifying the JWS Signature

1EdTech strongly recommends using an existing, stable library for this step.

5. Base64url-decode the JWT Payload segment of the Compact JWS and parse it into a JSON object.

6. Convert the value of vc claim to an ClrCredential and continue with § 7.2.6.1 Verify a Credential VC-JWT Signature.

The JSON object MUST have the iss claim, and the value MUST match the id of the issuer of the ClrCredentialJwtPayload object. If they do not match, the credential is not valid.

The JSON object MUST have the sub claim, and the value MUST match the id of the credentialSubject of the ClrCredentialJwtPayload object. If they do not match, the credential is not valid.

The JSON object MUST have the nbf claim, and the NumericDate value MUST be converted to a DateTime, and MUST equal the issuanceDate of the ClrCredentialJwtPayload object. If they do not match or if the issuanceDate has not yet occurred, the credential is not valid.

The JSON object MUST have the jti claim, and the value MUST match the id of the ClrCredentialJwtPayload object. If they do not match, the credential is not valid.

If the JSON object has the exp claim, the NumericDate MUST be converted to a DateTime, and MUST be used to set the value of the expirationDate of the ClrCredentialJwtPayload object. If the credential has expired, the credential is not valid.

This standard supports the Linked Data Proof format using the Ed25519 Signature 2020 suite.

Perform these steps to attach a Linked Data Proof to the credential:

1. Create an instance of Ed25519VerificationKey2020 as shown in Section 3.1.1 Ed25519VerificationKey2020 of [LDS-ED25519-2020].

2. Using the key material, sign the credential object as shown in Section 7.1 Proof Algothim of [DATA-INTEGRITY-SPEC] to produce a Proof as shown in Section 3.2.1 Ed25519 Signature 2020 with a proofPurpose of "assertionMethod".

3. Add the resulting proof object to the credential proof property.

Verify the Linked Data Proof signature as shown in Section 7.2 Proof Verification Algorthim of [DATA-INTEGRITY-SPEC].

Issuers will need to manage asymmetric keys. The mechanisms by which keys are minted and distributed is outside the scope of this specification. See Section 6. Key Management of the IMS Global Security Framework v1.1.

All the proof formats in this specification, and all Digital Integrity proofs in general, require the verifier to "dereference" the public key from a URI. Dereferencing means using the URI to get the public key in JWK format. This specification allows the use of an HTTP URL (e.g. https://1edtech.org/keys/1) or a DID URL (e.g. did:key:123), but only requires HTTP URL support.

Verification is the process to determine whether a verifiable credential is an authentic and timely statement of the issuer or presenter respectively. This includes checking that: the credential 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.

Validation is the process of assuring the verifiable credential meets the needs of the verifier and other dependent stakeholders. Validating verifiable credentials is outside the scope of this specification.

The 1EdTech Validator performs verification as described here.

This section applies to Verifiable Credentials with a type of "ClrCredential".

1. Check that the ClrCredential conforms to the specification:

If the ClrCredential has a credentialSchema property, and the type of the CredentialSchema object is "1EdTechJsonSchemaValidator2019", check that the credential conforms to JSON Schema as shown in 1EdTech JSON Schema Validator 2019. If it does not, the credential does not conform to the specification.

Check that the credentialSubject is identified by an id and/or an identifier. If neither is present, the credential does not conform to the specification.

2. Check that the proof method is satisfied:

The ClrCredential may have a VC-JWT proof and one or more Linked Data proofs. In this case, the Linked Data proofs will be attached to the ClrCredential in the vc claim of the signed JWT Payload. You may accept any one proof for verification. You do not need to verify all the signatures.

3. Refresh the ClrCredential:

Refresh must be completed after checking the proof so that the verifier is not spoofed into receiving a refreshed ClrCredential from a bad actor.

If the refreshService property is present, and the type of the RefreshService object is "ImsCredentialRefresh", refresh the credential as shown in 1EdTech Credential Refresh Service and then repeat steps 1 and 2. If the refresh is not successful, continue the verification process using the original ClrCredential.

Only perform Refresh once. That is, do not complete Refresh a second time even if the refreshed ClrCredential also has a refreshService defined.

4. Check the status:

If the credentialStatus property is present, and the type of the CredentialStatus object is "1EdTechRevocationList", determine if the ClrCredential has been revoked as shown in 1EdTech Revocation List Status Method.

If the current date and time is before the issuanceDate, the ClrCredential is not yet valid.

If the current date and time is after the expirationDate, the ClrCredential is expired.

5. Optionally verify the subject (recipient):

A ClrCredential is about a person called the recipient. The recipient is identified in the credentialSubject (see ClrSubject) by id and/or one or more identifier (see IdentityObject). The id or identifier value to use for verification must be shared with the verifier in an out-of-band process such as by email. This is called the known value.

To verify the recipient using a known id, simply compare the known id with the id in the ClrSubject. If they are equal then the recipient is verified.

To verify the recipient using a known identifier such as email address follow these steps shown in § 8.2 Verify the Recipient Using an Identifier. If you find a match then the recipient is verified.

If no match is found, the recipient is not verified.

6. Verify nested verifiable credentials:

A ClrCredential usually contains nested verifiable credentials in the credentialSubject. A ClrCredential may also contain nested EndorsementCredentials. If the nested verifiable credential has a type of "AchievementCredential" or "OpenBadgeCredential", verify the nested credential as shown in section "OpenBadgeCredential Verification" of the Open Badges Specification v3.0. If the nested verifiable credential has a type of "EndorsementCredential", verify the nested credential as shown in section "EndorsementCredential Verification" of the Open Badges Specification v3.0.

If all the above steps pass, the ClrCredential may be treated as verified.

The known identifier MUST be a plaintext string value. The known identifier type MUST be one of the types in IdentifierTypeEnum or an extension type. For example, if the known identifier is an email address, the known identifier type is emailAddress.

The ClrCredential issuer may include multiple identifiers that can be used for verification. The verifier should compare the known identifier (e.g. known email address) with all the identifiers included by the issuer until a match is found.

1. If identifier.identityType does not match the known identifier type, skip to the next identifier.

2. If identifier.hashed is true, calculate the known identifier IdentityHash using the known identifier and the identifier.salt. If the known identifier IdentityHash matches the identifier.identityHash, the recipient is verified.

3. If identifier.hashed is false, and if the known identifier matches the identifier.identityHash, the recipient is verified.

Credential equality and comparison is the process to determine whether a verifiable credential is semantically equivalent to another one.

A Host SHOULD treat a credential as the same as another when both the issuer id and the ClrCredential id are equal after unescaping of any percent encoded characters [RFC3986] followed by truncation of leading and trailing whitespace.

If the two credentials are equal according to the above, then the credential with the newer issuanceDate is the more up-to-date representation and could be interpreted as a replacement of the prior issued credential.

Credentials A and B are equal since they have the same id and the same issuer.id.

Since they also have the same issuanceDate both are up-to-date.

Credentials C and D are equal since they have the same id and the same issuer.id.

# data[].attributes.attachment_link.title
Comprehensive Learner Record Standard Version 2.0 | IMS Global Learning Consortium

# data[].attributes.body
Recruitment officer accepting/trusting an XU credentials for recruiting process

# data[].attributes.body
Need a generator of VCs that invite a person with appropriate identification to accept a VC

Need a Individual Wallet application to accept/import a VC

Need an Employer (or other application) to allow accepting a submission from an individual containing VCs

# data[].attributes.body
we encourage as much transparency as possible, ie through an API that could be made public, which acts as an input to the engine. Aspects of the model could be shared, ie decision-making structure. Analysis of the bias of inputs and outputs is needed. Of course PII must be protected. We want to respect the IP and PII of the partners and sources. Engine is not expected to be public - the output are the models, they need to be public.

# data[].attributes.body
Interests:

Using AI (such as ChatGPT) to find competency frameworks quickly and easily that credential issuers can obtain to markup their credentials.

Tools for converting unstructured data in the form of profiles and associated evidence into standards-based LERs.

Tools for quickly finding relevant RSDs.

Please contact me if you have similar interests or available tools: kathleen@skillsquirrel.com

# data[].attributes.body
Yes! Any kind of chat model could use this.

# data[].attributes.body
Validate and verify seem to be important considerations.

# data[].attributes.body
For Higher Ed - trusted data issuers in a variety of forms-  most prominent is PDF artifacts.
Diplomas and certificates are also candidate artifacts for conversion.

# data[].attributes.body
across Enrolment / Recruiting use cases

# data[].attributes.headline
Does not have to be US-based data models!

# data[].attributes.subject
Does not have to be US-based data models!

# data[].attributes.body
eg ELM

# data[].attributes.body
Interaction with existing transcripts and vice versa.

# data[].attributes.body
would be great to crosswalk between the models used

# data[].attributes.body
A measure of success of the LER experiment would be that you can track and trace the origin of the data and the algorithms, automatically detect tampering by human or AI, and be able to reverse experiments that did not bring the AI closer to its intended functionality in its intended domain.

# data[].attributes.headline
multi-user workflow cloud based platform

# data[].attributes.subject
multi-user workflow cloud based platform

# data[].attributes.body
this would be a multi-user web based workflow system, where different users (AI engineer, MLOps engineer, stakeholder) would see different perspectives. AI engineer can introduce new experiments, MLOps can reproduce experiments and review performance of the model, and stakeholder can reject the model and add feedback from consumers.

# data[].attributes.headline
should the output VC include the fact that AI helped develop it?

# data[].attributes.subject
should the output VC include the fact that AI helped develop it?

# data[].attributes.body
And any measures of bias and skew?

# data[].attributes.body
https://www.ibm.com/topics/data-mesh

# data[].attributes.attachment_link.readable_text
What is a data mesh?

Learn what a data mesh is, how it relates to a data fabric and how it uses decentralization to democratize data across a large organization

A data mesh is a decentralized data architecture that organizes data by a specific business domain-for example, marketing, sales, customer service, and more-providing more ownership to the producers of a given dataset. The producers' understanding of the domain data positions them to set data governance policies focused on documentation, quality, and access. This, in turn, enables self-service use across an organization. While this federated approach eliminates many operational bottlenecks associated with centralized, monolithic systems, it doesn't necessarily mean that you can't use traditional storage systems, like data lakes or data warehouses. It just means that their use has shifted from a single, centralized data platform to multiple decentralized data repositories.

It's worth noting that data mesh promotes the adoption of cloud native and cloud platform technologies to scale and achieve the goals of data management. This concept is commonly compared to microservices to help audiences understand its use within this landscape. As this distributed architecture is particularly helpful in scaling data needs across an organization, it can be inferred that a data mesh may not be for all types of businesses; that is, smaller businesses may not reap the benefits of a data mesh as their enterprise data may not be as complex as a larger organization.

Zhamak Dehghani, a director of technology for IT consultancy firm ThoughtWorks, is credited for promoting the concept of data mesh as a solution to the inherent challenges of centralized, monolithic data structures, such as data accessibility and organization. Its adoption was further spurred by the COVID-19 pandemic in an effort to drive cultural change and reduce organizational complexity around data.

A data mesh involves a cultural shift in the way that companies think about their data. Instead of data acting as a by-product of a process, it becomes the product, where data producers act as data product owners. Historically, a centralized infrastructure team would maintain data ownership across domains, but the product thinking focus under a data mesh model shifts this ownership to the producers as they are the subject matter experts. Their understanding of the primary data consumers and how they leverage the domain's operational and analytical data allows them to design APIs with their best interests in mind. While this domain-driven design also makes data producers responsible for documenting semantic definitions, cataloguing metadata and setting policies for permissions and usage, there is still a centralized data governance team to enforce these standards and procedures around the data. Additionally, while domain teams become responsible for their ETL data pipelines under a data mesh architecture, it doesn't eliminate the need for a centralized data engineering team. However, their responsibility becomes more focused on determining the best data infrastructure solutions for the data products being stored.

Similar to how a microservices architecture couples lightweight services together to provide functionality to a business- or consumer-facing application, a data mesh uses functional domains as a way to set parameters around the data, enabling it to be treated as a product which can be accessed to users across the organization. In this way, a data mesh allows for more flexible data integration and interoperable functionality, where data from multiple domains can be immediately consumed by users for business analytics, data science experimentation and more.

As previously stated, a data mesh is a distributed data architecture, where data is organized by its domain to make it more accessible to users across an organization. A data lake is a low-cost storage environment, which typically houses petabytes of structured, semi-structured and unstructured data for business analytics, machine learning and other broad applications. A data mesh is an architectural approach to data, which a data lake can be a part of. However, a central data lake is more typically used as dumping ground for data as it frequently is used to ingest data that does not yet have a defined purpose. As a result, it can fall victim to becoming a data swamp-i.e. a data lake that lacks the appropriate data quality and data governance practices to provide insightful learnings.

A data fabric is an architecture concept, and it focuses on the automation of data integration, data engineering, and governance in a data value chain between data providers and data consumers. A data fabric is based on the notion of "active metadata" which uses knowledge graph, semantics, and AI / ML technology to discover patterns in various types of metadata (for example system logs, social, etc.) and apply this insight to automate and orchestrate the data value chain (for example enable a data consumer to find a data product and then have that data product provisioned to them automatically). A data fabric is complimentary to a data mesh as opposed to mutually exclusive. In fact the data fabric makes the data mesh better because it can automate key parts of the data mesh such as creating data products faster, enforcing global governance, and making it easier to orchestrate the combination of multiple data products.

Data democratization: Data mesh architectures facilitates self-service applications from multiple data sources, broadening the access of data beyond more technical resources, such as data scientists, data engineers, and developers. By making data more discoverable and accessible via this domain-driven design, it reduces data silos and operational bottlenecks, enabling faster decision-making and freeing up technical users to prioritize tasks that better utilize their skillsets.

Cost efficiencies: This distributed architecture moves away from batch data processing and instead, it promotes the adoption of cloud data platforms and streaming pipelines to collect data in real-time. Cloud storage provides an additional cost advantage by allowing data teams to spin up large clusters as needed, paying only for the storage specified. This means that if you need additional compute power to run a job in a few hours vs. a few days, you can easily do this on a cloud data platform by purchasing additional compute nodes. This also means that it improves visibility into storage costs, enabling better budget and resource allocation for engineering teams.

Less technical debt: A centralized data infrastructure causes more technical debt due to the complexity and required collaboration to maintain the system. As data accumulates within a repository, it also begins to slow down the overall system. By distributing the data pipeline by domain ownership, data teams can better meet the demands of their data consumers and reduce technical strains on the storage system. They can also provide more accessibility to data by providing APIs for them to interface with, reducing the overall volume of individual requests.

owners agree on how to standardize domain-agnostic data fields upfront, which facilitates interoperability. This way, when a domain team is structuring their respective datasets, they are applying the relevant rules to enable data linkage across domains quickly and easily. Some fields commonly standardized are field type, metadata, schema flags, and more. Consistency across domains enables data consumers to interface with Interoperability: Under a data mesh model, data APIs more easily and develop applications to serve their business needs more appropriately.

Security and compliance: Data mesh architectures promote stronger governance practices as they help enforce data standards for domain-agnostic data and access controls for sensitive data. This ensures that organizations follow government regulations, like HIPPA restrictions, and the structure of this data ecosystem supports this compliance through the enablement of data audits. Log and trace data in a data mesh architecture embeds observability into the system, allowing auditors to understand which users are accessing specific data and the frequency of that access.

While distributed data mesh architectures are still gaining adoption, they're helping teams attain their goals of scalability for common big data use cases. These include:

Business intelligence dashboards: As new initiatives arise, teams commonly require customized data views to understand the performance of these projects. Data mesh architectures can support this need for flexibility and customization by making data more available to data consumers.

Automated virtual assistants: Businesses commonly use chatbots to support call centers and customer service teams. As frequently asked questions can touch on various datasets, a distributed data architecture can make more data assets available to these virtual agent systems.

Customer experience: Customer data allows businesses to better understand their users, allowing them to provide more personalized experiences. This has been observed in a variety of industries from marketing to healthcare.

Machine learning projects: By standardizing domain agnostic data, data scientists can more easily stitch together data from various data sources, reducing the time spent on data processing. This time can help to accelerate the number of models which move into a production environment, enabling the achievement of automation goals.

IBM Solutions

IBM Cloud Pak for Data

IBM supports the implementation of a data mesh with the IBM Data Fabric on Cloud Pak for Data. The IBM Data Fabric is a unified solution that contains all the capabilities needed to create data products and enable the governed and orchestrated access and use of these data products. The IBM Data Fabric enables the implementation of a data mesh on any platform (e.g., on premises data lakes, cloud data warehouses, etc.), allowing true enterprise-level self-service and re-use of data products regardless of where the data is.

IBM supports the implementation of a data mesh through its data fabric solutions. IBM's approach to a data fabric is solving for four key common customer pain points: Data Governance & Privacy, Multicloud Data Integration, MLOps and Trustworthy AI and Customer 360, all of which are delivered on its hybrid cloud platform, IBM Cloud Pak for Data. Learn more about IBM Cloud Pak for Data

# data[].attributes.attachment_link.description
Learn what a data mesh is, how it relates to a data fabric and how it leverages decentralization to democratize data across a large organization