search

w3c-ccg / vc-ed-models

https://w3c-ccg.github.io/vc-ed-models/
Other
9 stars 5 forks source link

Milestone 2: Issuer concept #32

Closed kimdhamilton closed 3 years ago

kimdhamilton commented 3 years ago

Milestone 2 tracks elaboration of vc-ed-models concept 6 -- issuer. It's defined as follows:

Concept 6 (issuer): describes the person or entity that is issuing the credential. In the education/occupational space, the issuer could be an institution, organization, or employer. The issuer may also be a person. For example: a person such as a colleague may issue a recommendation about another person in the form of a verifiable credentials.

In the use cases we've identified so far, issuer is of type Person or Organization. We want to keep peer issuers in scope.

The goals of this milestone are:

cc: @ottonomy @longpd @martyr280

kimdhamilton commented 3 years ago

Relevant Issuer details from IMS Global standards

Open Badges

Open Badges defines an Issuer / Profile

Sample is below, but note that only id and type are required. Work is underway to allow issuer DIDs in Open Badges, but I believe that is not necessarily planned to be the id property (TODO: dig up link)

{
  "@context": "https://w3id.org/openbadges/v2",
  "type": "Issuer",
  "id": "https://example.org/organization.json",
  "name": "An Example Badge Issuer",
  "image": "https://example.org/logo.png",
  "url": "https://example.org",
  "email": "contact@example.org",
  "publicKey": "https://example.org/publicKey.json",
  "revocationList": "https://example.org/revocationList.json"
}

Comprehensive Learner Record

Issuer same as Open Badges (TODO: link) sample from OCP implementation: 

  "publisher": {
    "official": "Authoritative Person",
    "parentOrg": {
      "id": "urn:uuid:c2f8de63-01d7-4c2d-ad73-78130713f063",
      "name": "A District",
      "address": {
        "streetAddress": "504 Somewhere Ave",
        "addressRegion": "ND",
        "addressLocality": "City",
        "postalCode": "58119",
        "addressCountry": "USA"
      },

"issuer": {
          "official": "Authoritative Person",
          "parentOrg": {
            "id": "urn:uuid:c2f8de63-01d7-4c2d-ad73-78130713f063",
            "name": "A District",
            "address": {
              "streetAddress": "504 Somewhere Ave",
              "addressRegion": "ND",
              "addressLocality": "City",
              "postalCode": "58119",
              "addressCountry": "USA"
            },
martyr280 commented 3 years ago

A couple of concepts that are important from the k12 context for transcripts:

amiller-ims commented 3 years ago

@kimdhamilton

Sample is below, but note that only id and type are required. Work is underway to allow issuer DIDs in Open Badges, but I believe that is not necessarily planned to be the id property (TODO: dig up link)

https://github.com/IMSGlobal/openbadges-specification/blob/develop/ob_next/dids-in-badges.md

longpd commented 3 years ago
  • the issuer is officially the school
  • the district authorizes the issuance of the assertion
  • the superintendent of the district is the official signature on the document i.e. they have the authority to issue the assertion
  • the assertion is officially issued by the State system as a proxy for the district/school

In your edits to the CLR JSON @martyr280 you have the Publisher with the name= "A District". Then later you have Issuer with the name = "A District" as well. By your comment wouldn't the issuer be the particular school, and the publishers the district within the school is located? Can you clarify that?

martyr280 commented 3 years ago

@longpd at the achievement level of the CLR we have a parentOrg and Org as below:

  "achievement": {
    "id": "urn:uuid:4a984234-44cd-462d-a7a2-7341aa91c9e5",
    "name": "Cumulative GPA",
    "issuer": {
      "official": "Authoritative user",
      "parentOrg": {
        "id": "urn:uuid:c2f8de63-01d7-4c2d-ad73-78130713f063",
        "name": "A District",
        "address": {
           "streetAddress": "504 Somewhere Ave",
           "addressRegion": "ND",
           "addressLocality": "City",
           "postalCode": "58119",
           "addressCountry": "USA"
        },
        "description": "District"
      },
      "id": "urn:uuid:1b659671-7ce7-4882-83aa-63fb2fa397d8",
      "name": "A High School",
      "sourcedId": "bf694b94-7198-2891-3d96-8485d1025e16",
      "address": {
        "streetAddress": "249 Anywhere St.",
        "addressRegion": "ND",
        "addressLocality": "Wilton",
        "postalCode": "58119",
        "addressCountry": "USA"
      },
      "telephone": "111-111-1111",
      "description": "School",
anthonycamilleri commented 3 years ago

Some additional thoughts on my side around issuers, based on examples we have in Europe:

All of these examples also require distinguishing between the 'certificate issuer' and the 'achievement issuer'.

kimdhamilton commented 3 years ago

@anthonycamilleri and I discussed a few options, which we'll discuss 22 Feb.

I just added Option 4, which questions whether this is in scope for Issuer. I can see the above cases being most flexibly addressed through capabilities, endorsements, separate assertions, and/or chained assertions. This task force may release recommendations about how to accomplish this (patterns), based on use cases we decide are in scope.

kimdhamilton commented 3 years ago

Other notes from discussion with @anthonycamilleri:

anthonycamilleri commented 3 years ago

Some more thoughts here. European data protection legislation makes a distinction between a data processor and a data controller. The controller is the organisation that is actually responsible for the management of the user data, while the data processor is only responsible for processing data on explicit instructions from the controller. It is not clear which of these organisations in a relationship would be considered an issuer.

martyr280 commented 3 years ago

@anthonycamilleri the concept of a processor and controller make sense, does the data controller moniker also dictate ownership or is that another entity. In the case of the example above the district "owns" the data.

longpd commented 3 years ago

I like the use of the GDPR distinction in Anthony has suggested. For our purposes I think the concern associated with who has the responsibility for the assertions about learning, where "responsibility" means they provided the training, stand behind the integrity of the instructional process and back the assertion as representing their assessed opinion of the learner's accomplishing demonstrating the performance requirements necessary for the assertion made. Technically issuing the certification, is in the GDPR sense acting as a data processor. In the usual context of university instruction in the US the institution that confers the certificate, degree, or credential is responsible for the user data. They keep a copy of it. They have independent responsibilities for reporting their use of funds to the government justifying the money has been properly spent on educational practices that resulted in the credential being awarded.

What's unique in the current technology environment is the learner has an equally tamper-evident representation of the assertion or credential. But they cannot alter it or otherwise change anything about it without such modifications becoming evident. But they can send it, including packaging it with other credentials they have been issued in a presentation to a third-party - e.g., an employer or another educational institutions (the verifyer in the trust triangle).

The part that I'm still concerned about here is what could be construed as simply a data processing step, the cryptographic signing of the credential, must remain a step the issuer, that is the institution responsible for the integrity of the education, performs. That is the unique and only way to retain the provenance of the credential.

Therefore I'd argue that we use the term 'issuer' as analogous to the organization that signs the credential, and that this must be the same organization that is responsible for the integrity of the learning experience, its assessment and the only entity with permission to alter the credential contents.

Why is this important? There is much talk in the US of issuing a credential, meaning creating the data payload and signing it on behalf of the institution that actually designed, delivered, and assessed the outcome of the instruction. That sounds very much like a slippery slope obfuscating the chain of ownership and provenance of the responsibility for and integrity of the credential this signed when its signed 'by proxy'.

Yes, it may be convenient for the educational institution to effectively subcontract out this apparently simple data processing activity. But the consequences are deep and not well understood. Better would be to insure that the VC process can enable an educational institution control their own private key and/or cryptographic signing function themselves. They may do nothing more than supply the data therein to a third party to prepare data payload for signing, but the must sign it themselves.

larinyo commented 3 years ago

My two cents (from the work been done in EBSI):

In some quality assurance model, it is not just the educational institution that issues the credential that can change the status of a previously issued VC/VA. Other authorized accreditation bodies may act on the status of the VC/VA (for example, a judge initiating a formal investigation to determine if the credential is valid may suspend the VC/VA itself, so no one can say that it has been revoked, or that is valid. Or the Ministry of Universities may revoke a Credential issued by a university for official degrees).

Regarding to GDPR: The GDPR describes two types of actors that are fundamental responsible entities in data processing: the data controller and the data processor.

The data controller is ‘natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law’.

The data processor is ‘a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller’.

Every time personal data processing takes place, the GDPR allocates responsibility among liable actors. It is thus, essential that at least one data controller be identified within the process. However, there is no absolute need for a separate entity operating as a data processor since the functions can be performed by the data controller.

Data controllers have a predefined set of obligations, laid out in various parts in the GDPR. As per article 25 GDPR, the data controller “shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed”.

Overall, data controllers are in charge of the data processing operation and the network of actors that they create around them. For instance, data controllers are obligated to provide contact information to the data subjects, but also to decide and accommodate the details of any data processor relationship that they might create for the data processing at hand. The responsibilities that weigh on them illustrates the central role that the data protection framework attributes to this entity.

The natural or legal person that will be determined to be a data controller, demonstrates the exercise of “decision-making power” on certain key elements on data processing. In order to determine that, the analysis looks at specific processing operations and aims to understand the “why and the how” of the data processing control operation.

The responsibility of a controller is dependent on the stages of the processing in which the respective actor is involved, and on the degree of this involvement. In practical terms (e.g., for EBSI), this means that not every data controller is sharing the same amount of liability. The de facto appreciation will showcase how the different responsible actors will be held liable. For instance, the participation of a consortium (e.g., the EBSI consortium) as a joint data controller who participates in defining the essential means of data processing will be proportionately reduced to reflect the participation of the entity in the data processed.

The determination of the means signifies, in the case of distributed ledgers, the decision-making power over the software architecture, the data centers constituting nodes, and the terms of the data processing. This base layer architecture is determined by the respective consortium (e.g., EBSI consortium). They are the ones designing the means of the processing of data, determining the terms of the contract for the respective nodes, and the requirements that these nodes would have to abide by in order to be onboarded.

With respect to permissioned blockchains (e.g., EBSI) and for the data processed on the distributed ledger, nodes are more likely to be qualified as data processors than as controllers. They are executing the necessary software to ensure consensus, but have little control over the determination of the means or the purposes of the processing.

Hired to perform the necessary computations, the nodes of the network could be considered as joint controllers on the personal data stored in the distributed database that constitutes the ledger, ONLY IF they have the power to arguably determine the essential means of the processing.

However, the relationship between the consortium and the regulation of data processing mechanisms could be that of controllership solely for the personal data that are circulating on the distributed ledger. The participation of the consortium members in the determination and design decisions of the essential means of data processing in the network could qualify them as accountable actors. In that sense, the use case operators (de facto data controllers for the respective personal data processing they enable, as we will elaborate further), knowingly enable the personal data to be processed on the ledger whose means of data processing is predominantly designed by the consortium.

Educational use case ensures the direct and secure transaction of Verifiable Credentials (VC) or Verifiable Attestations (VA) between educational institutions and individuals. Specifically, citizens that have been enrolled at the onboarded institutions can receive and safely store in their personal wallets, a digital representation of their diplomas. For these transactions, there needs to exist a network of identified actors and entities.

Firstly, the DID Registry will hold the DIDs of both educational institutions (a priori not personal data) and the DIDs of individuals. Since the latter can refer to an identified individual, it will be de facto considered as personal data and thus the DID Registry operator will have to be considered for its responsibility due to its participation in the data processing chain.

The responsible legal entities operating this registry will be the educational institutions that can also function as Trusted Issuers, or legal entities (accreditation bodies) that can also function as Trusted Accreditation Organization (TAO). The registry will hold DIDs and public keys of both educational institutions and students wishing to be onboarded to be able to use the application. Naturally, the registries that involve solely registration of authorities, educational institutions, and other legal entities, do not a priori seem to contain personal data and are thus exempt from this consideration.

The registration process for students and thus natural persons, does involve the registration of DIDs and public keys which are, by definition, personal data. Thus, as previously explained, whether these educational institutions operate under the concrete instructions and interests of the use case operators or whether they have a degree of autonomy in deciding the means of the processing will be essential in the qualification of these educational institutions as data controllers. It is relevant to point out that these institutions are already considered as controllers for the conventional personal data that they hold on their students. After the issuance process of the Diploma, these institutions anchor this fact on chain in order to register the issuance or any relevant credential or presentation that has been requested.

Hope this helps. This is a delicate subject, where each scenario must be thoroughly analyzed, no two scenarios are the same. The identification of previous roles and responsibilities is contextualized in the case of EBSI and Diploma Use Case.

PS Of course, students' DID register in the DID Registry is made by themselves (no 3rd party or proxies on behalf of them), same applies for legal entities. Kim, the latest "Governance" slides I shared to you reflect the main EBSI Registries and how the "Business/Domain Governance" relate to them.

kimdhamilton commented 3 years ago

This discussion is reinforcing my nagging feeling that the issuer/related authority variations mentioned in this thread may be out of scope for the base definition of issuer for a couple of reasons:

On the call today, I'd like to prioritize discussing the following:

This is an area we can come back to, whether as a separate milestone for this deliverable, or as a subsequent task force deliverable.

kimdhamilton commented 3 years ago

22 Feb discussion:

kimdhamilton commented 3 years ago

Recommended changes:

  1. Update definition of issuer to clarify that the issuer doesn't necessarily have relationship to learning experience that led to the credential
  2. Issuer description highlights:
    • We use the term Issuer in the same sense as in the VC-DATA-MODEL with no additional semantics.
    • From the VC-DATA-MODEL: "The value of the issuer property MUST be either a URI or an object containing an id property."
      • Proposal: add "dereferenceable URI"
    • In the object form:
      • The only required property from VC-DATA-MODEL is id.
      • Also require type (similar to OB)
      • Recommend (but not require) name?
      • For interoperability, use schema.org types Person or Organization

Discussion/Application:

OB Issuer/Profile defines the following properties. [R] denotes required by OBv2, [S] denotes whether the property is defined on schema.org Person AND Organization:

OB's LD context defines [S] properties as schema.org types.

kimdhamilton commented 3 years ago

Discussion:

martyr280 commented 3 years ago

Ex. "issuer": { "official": "Macy Wood", "parentOrg": { "id": "urn:uuid:c2f8de63-01d7-4c2d-ad73-78130713f063", "name": "Wilton Public School District", "address": { "streetAddress": "504 Dakota Ave", "addressRegion": "ND", "addressLocality": "Wilton", "postalCode": "58579", "addressCountry": "USA" }, "description": "District" }, "id": "urn:uuid:1b659671-7ce7-4882-83aa-63fb2fa397d8", "name": "Wilton High School", "sourcedId": "bf694b94-7198-2891-3d96-8485d1025e16", "address": { "streetAddress": "PO Box 249", "addressRegion": "ND", "addressLocality": "Wilton", "postalCode": "58579", "addressCountry": "USA" }, "telephone": "701-734-6331", "description": "School", "identifiers": [ { "identifier": "2", "identifierType": "ext:LeaSchoollId" }, { "identifier": "2800194510712", "identifierType": "ext:SeaSchoolId" }, { "identifier": "381320000457", "identifierType": "ext:NcesSchoolId" } ] }

kimdhamilton commented 3 years ago

^ CLR example

kimdhamilton commented 3 years ago

3/29: approved; ready to close