- From: Snorre Lothar von Gohren Edwin <snorre@diwala.io>
- Date: Wed, 1 Jun 2022 11:50:14 +0200
- To: Nate Otto <nate@ottonomy.net>
- Cc: dzagidulin@gmail.com, public-vc-edu@w3.org
- Message-ID: <CAE8zwO2uuvZ8fCiGhxL7QMtAVZCYjvpRRoEUparTrBxJACh-Wg@mail.gmail.com>
In reply to 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?". This is where presentation exchange comes in and solves this. See here: https://identity.foundation/presentation-exchange/#submission-requirement-feature. See multi group example You would add into the PE object, I want "3DPrinterAuthorization" types. They have to be issued by issuer X They have to have achivement value of Machine X. When using PE you define objects that you are requesting based on attributes inside the VC. Which makes this combo very powerful. PE is not locked to any stack, it can be used in DIDCOM, OpenIDconnect, chapi or whatever. Does this solve your problem Nate? Should I move this to https://github.com/IMSGlobal/openbadges-specification/issues/339? ᐧ On Tue, May 31, 2022 at 11:32 PM Nate Otto <nate@ottonomy.net> wrote: > @Dmitri, thanks for replying with your thoughts. > > > I want to suggest that -- the 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 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'." 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 > -- *Snorre Lothar von Gohren Edwin* Co-Founder & CTO, Diwala +47 411 611 94 www.diwala.io <http://www.diwala.io/> *Stay on top of Diwala news on social media! **Facebook <https://www.facebook.com/diwalaorg>** / **LinkedIn <https://www.linkedin.com/company/diwala>** / **Instagram <https://www.instagram.com/diwala_/>** / **Twitter <https://twitter.com/Diwala>*
Received on Wednesday, 1 June 2022 09:50:41 UTC