AchievementCredential id

[kayaelle]

The id property of the AchievementCredential is required "so it can be the subject of an endorsement." It's suggested that this be changed to optional since not all Open Badges will be endorsed and not all issuers should be required to provide a URI for an AchievementCredential. Please note that the VC-EDU recommendation will make this property optional in line with the VC spec.

[ottonomy]

Interesting, so we want it to be possible for an issuer to issue an assertion that is not possible to be endorsed by others down the road? What is the use case for disallowing the recipient from collecting endorsements for a particular AchievementCredential, and if there is a use case for that, is the issuer the sole party that should make that decision?

[kayaelle]

Endorsements may not be relevant use cases for all credentials. Does a student id need to be endorsed?

It's a thin argument to say that an optional property disallows functionality that is not yet happening very much. Endorsements, hashlinking, and other potential functionality could be enabled by including an id. The argument for this issue isn't that an id is a bad idea, just that it should be optional, not required.

Primarily: Why would the use case for requiring an id in the form of a UUId or URL for Open Badges supersede the VC spec that does not require it. If Open Badges requires it and VCs doesn't that somewhat diminish Open Badges being aligned to VCs?

Can a recommendation (a may not a must) to include an id be sufficient for issuers?

Update to the original submission: we'll bring this up for discussion at a VC-EDU meeting in the near future to see what the open community thinks to determine what the recommendation will be out of that task force.

[amiller-ims]

Primarily: Why would the use case for requiring an id in the form of a UUId or URL for Open Badges supersede the VC spec that does not require it. If Open Badges requires it and VCs doesn't that somewhat diminish Open Badges being aligned to VCs?

I don't want to derail this conversation, but want to offer that as a Standards Development Organization, 1EdTech (IMS) has a policy for profiling and extending our specifications as needed for more specific implementations. Profiles can make an optional property required, but cannot make a required property optional. To use 1EdTech language, OB and CLR are Profiles (and Extensions) of the VC standard. For example, if VC were a 1EdTech standard, making the id required in OB and CLR would be allowed. I don't know W3C's policy (or if they have a policy) for what is allowed/encouraged when one of their standards is profiled.

[amiller-ims]

The [vc-data-model] makes an argument against requiring the id in Section 4.2 Identifiers and Section 7.3 Identifier-Based Correlation, concluding, "Where privacy is a strong consideration, the id property MAY be omitted."

[kayaelle]

Thanks for clarifying that @andyfmiller

[kayaelle]

To accompany #428, from a portability, accessibility, and privacy standpoint, please don't require this id.

If you do, please don't store the JSON-LD at the URI and also, give learners privacy controls over that webpage.

As I noted in the other issue, if one is interested in using hosted data, they could consider not updating. 3.0 is intended to be portable and accessible to the individual throughout their lifetime. The point is that they can control access to this data not the issuer. 2.0 will continue to be a valid spec just as previous versions are. It seems strange to force centralized notions on intended decentralized implementations when the centralized-based spec continues to be valid. Why bother updating to 3.0 and then not using it to its full potential if it doesn't suit your application?

[msporny]

Just one more data point for the conversation:

The id property of the AchievementCredential is required "so it can be the subject of an endorsement."

You don't need id for a VC to be the subject of an endorsement. You can just include the VC wholesale in the endorsement VC. I realize that's a bit heavy-handed, but the argument that you NEED an id to do an endorsement doesn't seem to hold any water (to me, at least). Perhaps I'm missing some other requirement? Does anyone have an example of an Endorsement credential? Here's one example:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v2",
    "https://w3id.org/endorsement-experiment/v1" // <- TODO: decide on url
  ],
  "type": [ "VerifiableCredential", "ExperimentalVerifiableEndorsement" ],
  "issuer": {
    "id": "did:web:bob.example.com",
    "name": "Bob"
  },
  "issuanceDate": "2010-01-01T00:00:00Z",
  "expirationDate": "2020-01-01T00:00:00Z",
  "credentialSubject": {
    "type": "ExperimentalEndorsementCredential",
    "endorsedCredential": { ... VC being endorsed without `id` goes here ... }
    "endorsement": { ... endorsement goes here ... }
  },
  "proof": {
    // Signature goes here
  }
}

Seems like id in credential should remain optional, as the use case driving the requirement for id seems invalid?

[dlongley]

In addition to what @msporny just said...

Rather than requiring all VCs to have an id, it seems that the following advice could be given instead:

If you want it to be easy for a VC to be the subject of an endorsement without having to embed the entire VC, include an id in the VC so it can be referenced instead.

Reasons for not including an id could be given as well, e.g., to increase herd privacy when using selective disclosure. So, it's a trade off -- and, IMO, it would therefore be better for VC authors to be able to decide what is best based on the use case.

[amiller-ims]

Here is an example of a State DOE endorsing an issuer.

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://purl.imsglobal.org/spec/ob/v3p0/context.json"
  ],
  "id": "http://1edtech.edu/endorsementcredential/3732",
  "type": ["VerifiableCredential", "EndorsementCredential"],
  "issuer": {
    "id": "https://state.gov/issuers/565049",
    "type": ["Profile"]
    ],
    "name": "State Department of Education"
  },
  "issuanceDate": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "https://1edtech.edu/issuers/565049",
    "endorsementComment": "1EdTech University is in good standing"
  }
}

Endorsing an OpenBadge (now OpenBadgeCredential), issuer, or achievement description by id has a fairly long history in the Open Badges world. During that time, the OpenBadge, issuer, and achievement description id was a required field.

It makes sense to re-evaluate whether that is still the right method now that Open Badges are VCs. I don't think there is any controversy about requiring an issuer id or achievement description id, so endorsing either by id still works fine.

For the case of endorsing an OpenBadgeCredential, I think the suggestion to support either identifying the endorsed VC by id OR by embedding the endorsed VC in the endorsement credential could work. The workflow might look like this:

1. The college issues an OpenBadgeCredential representing an awarded degree to me and sends it to the State DOE.
2. The State DOE issues an EndorsementCredential that contains the OpenBadgeCredential and sends it to me.
3. I now have two VCs, one that is just the degree, and one that shows the degree is endorsed by the State DOE.

It'd be great of some of the Open Badge issuers (especially ones that support endorsements) weighed in.