Re: Issuer-specific achievements

I added some comments here too:  https://github.com/IMSGlobal/openbadges-specification/issues/428 <https://github.com/IMSGlobal/openbadges-specification/issues/428>


> On May 31, 2022, at 6:49 PM, Nate Otto <nate@ottonomy.net> wrote:
> 
> Thanks for the continuation. This is definitely worth a timely discussion to queue up a good joint CLR/OB workgroup meeting this Thursday. I've also added comments here: https://github.com/IMSGlobal/openbadges-specification/issues/428 <https://github.com/IMSGlobal/openbadges-specification/issues/428>
> 
> credential.type and credentialSubject.achievement.id <http://credentialsubject.achievement.id/> are indeed two different properties within a credential where we might do work that enables us to determine if a credential is fit for purpose and issued by the expected issuer. I often find value in expressing the intent of a credential issuer in plain human language to determine where within a JSON-LD structure the expected value should be encoded. 
> 
> In this case, I see this as a case of "I want to issue a Open Badge (Credential type) to Alice to recognize her achievement of Bachelor's of Science-as-defined-by-me (achievement id and metadata)."
> 
> Whereas you might see this as "I want to issue a Open Badge, Bachelor's of Science-as-defined-by-? (credential type) to Alice to recognize her achievement of her degree. I will provide additional metadata about the achievement within the credential."
> 
> In your example, the fundamental model of Open Badges would be different for 3.0 than it was for 1.0, 1.1, and 2.0, as far as I can tell. It would be more like "There is some organization, whoever is first perhaps, who defines a type of 'Bachelor's of Science', and then many institutions issue a credential of that type, and each award would contain whatever criteria and metadata that they consider specific to their interpretation of that concept. Correct me if I got your idea wrong.
> 
> Looking at another example of a badge that is more concretely tied to one specific organization, consider the Boy Scouts of America's "Eagle Scout" badge. How far have you thought through how a badge like this would work? Unlike the generic concept of a "Bachelor's Degree", the BSA authors the concept of "Eagle Scout" with the intent that only their own organization is ever permitted to award this badge. Have you thought of a particular mechanism that the BSA would use to encode this understanding into a credential so that verifiers and wallets could determine and display whether a particular award was created by the expected organization? In my eye this capability has been core to Open Badges since 1.0 and I don't expect the workgroup to be willing to abandon it as a requirement for conformant badge display.
> 
> Nate
> 
> 
> On Tue, May 31, 2022 at 3:08 PM Dmitri Zagidulin <dzagidulin@gmail.com <mailto:dzagidulin@gmail.com>> wrote:
> (Switching this over to a new thread, since this is out of scope for the JFF plugfest.)
> 
> Nate, I think there may be a mis-understanding here. 
> 
> > If we didn't have this default restriction, Harvard University might define a particular achievement for a Bachelor's Degree in Computer Science, and we wouldn't be able to differentiate between the real deal Harvard degree and impersonations.
> 
> Not at all - the value here is a tuple of Bachelors Degree, and the issuer (Harvard). With the achievement.id <http://achievement.id/> mechanism, you're trying to squish those two properties (achievement type, and issuer) into one (the id).
> 
> 
> On Tue, May 31, 2022 at 5:31 PM Nate Otto <nate@ottonomy.net <mailto:nate@ottonomy.net>> wrote:
> @Dmitri, thanks for replying with your thoughts.
> 
> > I want to suggest that -- the achievement.id <http://achievement.id/> field is a non-idiomatic way of fulfilling that usecase. achievement.type would make a lot more sense, and would match the usage in the general Verifiable Credentials community.
> 
> I think you haven't quite grasped the use case for "Does the user have credential X?", for example for a credential certifying a user as being qualified to use a specific 3D printer in a specific maker space.
> 
> The scenario here is not "holder, please present any VCs that may be related to 3DPrinterAuthorization from any issuer", it is "holder, can you present that you hold the specific achievement issued by this specific organization that claims you have met the criteria of its specific training program for using this specific 3D printer?". 
> 
> In Open Badges, a particular Defined Achievement has criteria and assessment that are particular to the creator. Other issuers are not permitted to issue valid credentials that are created by a particular achievement creator; this is pretty core to how Open Badges works. If we didn't have this default restriction, Harvard University might define a particular achievement for a Bachelor's Degree in Computer Science, and we wouldn't be able to differentiate between the real deal Harvard degree and impersonations. Open Badges has its mechanisms for doing this based on achievement.id <http://achievement.id/> and achievement.issuer/creator, and the workgroup will need to ensure that verification of this core feature still works efficiently under 3.0. It is use case #1 for Open Badges, so it's critical to deliver.
> 
> Open Badges 3.0 spec introduces a separate set of use cases (not "defined achievement") that correspond to something more akin to what you have paraphrased, "holder, please present any VCs that may be related to 3DPrinterAuthorization from any issuer", under the heading of "skills". That would be to ask for any VC that claims a user holds a particular skill, as recognized by any issuer, you would ask "holder, please present any VCs that claim that you hold skill 'htttps://sharableskills.example.org/skills/3DPrintingAdvanced' <http://sharableskills.example.org/skills/3DPrintingAdvanced'>." I expect the approach for this will depend on the "result.alignment.targetUrl" but am open to suggestions for alternate approaches. It's the critical 2 week period right now to deliver on this use case, so discussion <https://github.com/IMSGlobal/openbadges-specification/issues/339> is very welcome.
> 
> If it's your suggestion that IMS/1EdTech implement a significantly different mechanism in OB 3.0 for serving the most important use case in Open Badges than was used in 2.0, that's something that should be brought to the attention of the chairs of that workgroup immediately so that they can schedule appropriate time to address it before candidate final vote and release.
> 
> Nate