[USE CASE] - OpenCredentialPublisher

[martyr280]

Actor

Student graduating from a North Dakota high school

Submitter

Marty Reed, RANDA on behalf of the OpenCredentialPublisher project

User Story

Student requests a Transcript published to a web wallet signed as a verifiable credential.

Data Concepts

CLR JSON-LD, base64 encoded PDF, W3C-VC, assertions of each credential to be individually or asserted as a sub-group of the original credential.

Restrictions

credential must be expressed originally in IMS Global CLR JSON-LD format spec https://www.imsglobal.org/activity/comprehensive-learner-record VerifiableCredential-https___randaocpservice-test.azurewebsites.net_api_credentials_09c8efa6-39fb-4a39-8278-e55e229a41a8.zip

[kimdhamilton]

OpenSALT and course definition within North Dakota

Course code aligned course/sequence

[jmarks]

https://case.nd.gov/cfdoc/ contains all the state standards for all subjects as well as the course code framework

The course code framework is here: https://case.nd.gov/cftree/doc/28 with this URI: https://case.nd.gov/uri/1db82753-f8ca-5ff5-b932-b73cf6213287

The course code will link to the course expectations in the standards frameworks.

[kimdhamilton]

Select any of the tags below that apply or add your own

• [x] issuer-to-subject
• [x] subject-to-relying-party
• [ ] system-to-system
• [ ] peer-to-peer
• [x] subject-initiated
• [x] workforce
• [x] k-12
• [ ] post-secondary
• [ ] informal
• [x] e2e (i.e. issuer-to-subject-to-relying-party)
• [ ] multiple-issuers (i.e. multiple parties involved in credential issuance)

[martyr280]

@kimdhamilton edited tags as appropriate in your post, further descriptions below.

• issuer-to-subject : eTranscript system is the authoritative source of the data being published
• subject-to-relying-party : user may share their credentials with outside parties via secure link
• subject-initiated: I believe this to be a very important factor in the chain of custody discussion, only the user in the eTranscript system can initiate a publish of their credentials to the OCP, the eTranscript system does not auto-publish the originating credential therefore placing the custody of the credential in the user's hands. This also resolves the data-sharing agreement issues associated with k-12 record assertions. I would invite Matt Gee's comments here.
• workforce: we expect and have approached workforce consumers of k-12 credentials as consumers of these credentials
• k-12 currently the implementation is based on k-12 credential assertions however the OCP is generalized to allow any IMS Global CLR formatted credentials to be published via the OCP.
• e2e the OCP is intended to represent the entire lifecycle of the k-12 credential of a high-school graduate

[kayaelle]

@martyr280 and @jmarks - can you please add some details about how the student will be using the transcript from the wallet? Who or what will be verifying/consuming this data?

[jmarks]

@kayaelle Sure, Students will share their transcript or a view of a sub-set of the achievements on their transcript with a range of 3rd party verifiers: 1) Post secondary institutions are part of admissions and to enable enrollment, transfer and dual enrollment credits. 2) Apprenticeship program, particularly in CTE domains for entry qualifications 3) Prospective employers as part of the application and qualification review processes.

Additional consumers and verifies may include: 4) A "hub" or talent exchange like IBM's LCN, the National Student Clearing House "MyHub" or a service like LinkedIn. 5) Also of interest is to place a learner on a pathways or opportunity map on some future application service provider platform

[bumblefudge]

i wanna see all this in a swimlanes.io 😄

(so does the vc-http-api use cases debate)

side note: are there any "secondary wallets" or custodial wallets or wallets authorized to hold/present/parse/run ML on those "subsets"? is it too much of a conceptual stretch to call an OCP or a Clearing House a "secondary wallet" or a "service wallet" that publishes/disseminates a subset of the subject's records as a service defined by a contract? I'm not actually lobbying for the concept of a secondary wallet or a service wallet, just test-driving the terminological distinction to see how well it does or doesn't map this use case.

askingForAFriend #herNameIsVCHTTPAPI

[martyr280]

@bumblefudge we present the credentials through a sharing UI, including any human readable base64 object embedded in the originating CLR as well as the JWT object for consuming into tertiary systems. the front end of the OCP, the publishing service, follows the vc-http-api model pretty close https://randaocpservice-testclient.azurewebsites.net/ we have not exposed an API on the verifier consumer end as of yet, all controlled through the UI at this time.

[martyr280]

@bumblefudge