Re: Wallet segmentation question for our LER Ecosystem SmartReport

HI Phil,

Thank you for adding this to the discussion.

I’d like to challenge the community to think more about use cases like this and those related to access, control, and privacy. The LER focus has been on skills and competencies and how issuers can include these, how employers may use these and why they would trust them. This continues to be important but what about learner trust? In 2025, let’s talk more about why the tech matters and reasons why learners could trust these credentials more than centralized, cloud-based systems.

Best,

K.

From: Phillip D. Long <phil@rhzconsulting.com>
Date: Monday, January 6, 2025 at 7:50 PM
To: Simone Ravaioli <simone.ravaioli@parchment.com>
Cc: Kerri Lemoie <klemoie@mit.edu>, Ian Davidson <ian@idatafy.com>, Rob Coyle <rcoyle@1edtech.org>, Manu Sporny <msporny@digitalbazaar.com>, Deb Everhart <deverhart@credentialengine.org>, Nate Otto <nate@ottonomy.net>, Kate Giovacchini <kate.giovacchini@asu.edu>, Taylor Kendal <taylor@learningeconomy.io>, Chris Purifoy <chris@learningeconomy.io>, public-vc-edu@w3.org <public-vc-edu@w3.org>
Subject: Re: Wallet segmentation question for our LER Ecosystem SmartReport
I’d like to suggest there is one other dimension to portability concern here. A cloud-based credential wallet can provide many value-added services on top of the basic store and send VCs using VC ecosystem compatible protocols. But as a hosted service your credentials are stored, maintained and access to them gated by the hosted platform provider. That may be a trade off a user is willing to make for the convenience. But it does enable the provider to disable a user account preventing access by the user/holder to the credentials they are hosting.

I’m not suggesting that platform providers are ‘evil’ or would necessarily do that idiosyncratically. But as we’ve seen with other cloud service providers, there are terms of use that might be invoked to justify such an action.
I’m reminded of the case where a father discovered a rash on his child that was causing the kid severe discomfort. The rash wash on his son’s genitals. At his pediatrician's suggestion he took a couple of pictures of the rash and sent them to his son’s doc for him to the look and potentially make a recommendation about what to do. He used Gmail.

Google’s automated content inspection algorithm detected that pornographic images were being sent by this email address and immediately suspended the email account. The father got a message from Google saying his account was suspended and pending deletion. His account included his calendar, his Google Photos where all his pics of this son since birth were stored in that photo library and his email. He argued his case, invoked his lawyer for assistance and never regained access to his account, the pictures or anything else associated with it.

That’s clearly an extreme case, but it’s not inconceivable that it can happen to VCs. A set of medical images used as evidence to support a student’s credential issued as an OBv3 might include images some provider and their surveillance software could classify as inappropriate and a violation of their terms of use. The point is simply that a cloud service that doesn’t have local back up to the personal device of the account holder is a potential risk and on the border of principles behind portability, decentralized architecture and ownership one’s records the VC world advocates. Things that matter need to be in the possession of those they matter to.

Cheers,

  Phil


Phillip Long, Ph.D.

CEO, RHz Consulting, LLC.
Inquire-Listen-Design-Prototype-Analyze-Repeat
e: phil@rhzconsulting.com<mailto:phil@rhzconsulting.com>
LinkedIn: http://www.linkedin.com/in/longpd/<https://www.linkedin.com/in/longpd>
T: (434) 234-4479
—
LER Network Consultant
T3 Innovation Network, US Chanber of Commerce Foundation
https://t3networkhub.org

e: phil@rhzconsulting.com<mailto:phil@rhzconsulting.com>,
SNS: Telegram @RadHertz
Signal: 5129691774
LinkedIn: https://www.linkedin.com/in/longpd



On Jan 6, 2025, at 12:45 PM, Simone Ravaioli <simone.ravaioli@parchment.com> wrote:

"Not all OBv3 are created equal"

Some are implementing key SSI features like DIDs, others are still using email addresses as identifiers
Some are pushing OBv3 into SSI wallets (not web-based), others are still hosting them on platforms in the cloud

The 1EdTech OBv3 compliance test is only a partial proxy to determine whether an OBv3 is a VC.

Given the number of OBv3 certified platforms, I think a "retro" of the OBv3 implementations (in production) would be in place at this point to look under the hood - and eventually inform the ecosystem map.
Btw, I have suggested this already to the 1EdTech Product Steering Committee back in November.

We can offer to host a chat next Monday's VC EDU to discuss openly further.

Simone

On Mon, Jan 6, 2025 at 6:22 PM Kerri Lemoie <klemoie@mit.edu<mailto:klemoie@mit.edu>> wrote:
Hi Ian,

Here’s a couple of ways I can think that OBv2 platforms could also issue OBv3:

1) Add a share to wallet function that would issue/sign an OBv3 to a VC wallet
2) Provide a way to download a signed OBv3 as a JSON file or a baked image (as Credly does).

Both of these options provide the learners with portable credentials they can use privately and the possibility of avoiding vendor lock.  These options provide a way for OBv2 platforms to transition to OBv3 while maintaining their current model.

What you are trying to explain to the ecosystem is challenging. I think the key is to consider which platforms offer the issuance of portable, verifiable credentials that can exist and be verified outside of the platform and those that don’t. That’s really an oversimplification because it doesn’t address the nuances of blockchain platforms that use private or public ledgers with the vocabularies associated with VCs and OBv3 – but I believe that would be a new topic entirely.

Thanks,

K.

From: Ian Davidson <ian@idatafy.com<mailto:ian@idatafy.com>>
Date: Monday, January 6, 2025 at 11:31 AM
To: Kerri Lemoie <klemoie@mit.edu<mailto:klemoie@mit.edu>>
Cc: Rob Coyle <rcoyle@1edtech.org<mailto:rcoyle@1edtech.org>>, Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>, Deb Everhart <deverhart@credentialengine.org<mailto:deverhart@credentialengine.org>>, Nate Otto <nate@ottonomy.net<mailto:nate@ottonomy.net>>, Phillip D. Long <phil@rhzconsulting.com<mailto:phil@rhzconsulting.com>>, Kate Giovacchini <kate.giovacchini@asu.edu<mailto:kate.giovacchini@asu.edu>>, Taylor Kendal <taylor@learningeconomy.io<mailto:taylor@learningeconomy.io>>, chris purifoy <chris@learningeconomy.io<mailto:chris@learningeconomy.io>>, public-vc-edu@w3.org<mailto:public-vc-edu@w3.org> <public-vc-edu@w3.org<mailto:public-vc-edu@w3.org>>
Subject: Re: Wallet segmentation question for our LER Ecosystem SmartReport
Happy New Year indeed everyone!

This ecosystem report defines the ecosystem of LERs as the technologies/companies/orgs involved in the issuance, sharing/portability, and consumption of OB2 and OB3s, CLR1s and CLR 2s and the LER-RS.  It is not the Verifiable Credential ecosystem, though we do go to great lengths to explain the overlap between the two and how VCs are involved in LERs.  We include that definition of this specific view of this ecosystem right at the start of the report.

That said, we support the movement toward OB3s and embracing the decentralized strengths of VCs.  We include that as a key trend as an attempt to signal the importance that LERs continue to evolve in that direction.

I do think the definitions of the "on-platform credential management" segment needs some work.  I'm reaching out today and tomorrow to the companies shown there to get a better understanding for how their support of OB3 will work.  Rob is right that some of these platforms already do support OB3 or say they will in 2025. We hope the SmartResume logo will be added to that segment in next year's report when we enable the sharing of SmartResume's as an LER-RS.  LER.me also anticipates being included in this segment as they are building credential management tools into the platform and I believe those will focus on OB3s as well.

Kerri - can you share your current understanding of issuing platforms that issue both OB2 and OB3 and how their credential management tools work for OB3?  I would think if you're issuing an OB3 then the verification does not tie back to your platform - that feels like the key question/concern raised here if I'm following things correctly.



On Mon, Jan 6, 2025 at 9:48 AM Kerri Lemoie <klemoie@mit.edu<mailto:klemoie@mit.edu>> wrote:
Hi Rob,

Interesting. I think the group (and I ) could use some clarification about how those platforms are issuing OBv3 and work as Ian describes: “These tools are web-based and do not meet the criteria of self-sovereign credential wallets. But they do allow credentials to be aggregated and moved into directly integrated websites and platforms like LinkedIn or Facebook where the credential may be shared as a link back to the issuing platform rather than as a fully portable asset.”

Could you provide some examples of how platforms are issuing OBv3 that don’t work like VCs? I know of some that are issuing both OBv2 and OBv3. If any of those platforms are on this mailing list, would love to learn more about your implementations.

Thanks,

K.

P.S. Happy New Year, all! Hit the ground running….

From: Rob Coyle rcoyle@1edtech.org<mailto:rcoyle@1edtech.org>,
Date: Monday, January 6, 2025 at 10:41 AM
To: Kerri Lemoie <klemoie@mit.edu<mailto:klemoie@mit.edu>>
Cc: Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>, Ian Davidson <ian@idatafy.com<mailto:ian@idatafy.com>>, Deb Everhart <deverhart@credentialengine.org<mailto:deverhart@credentialengine.org>>, Nate Otto <nate@ottonomy.net<mailto:nate@ottonomy.net>>, Phillip D. Long <phil@rhzconsulting.com<mailto:phil@rhzconsulting.com>>, Kate Giovacchini <kate.giovacchini@asu.edu<mailto:kate.giovacchini@asu.edu>>, Taylor Kendal <taylor@learningeconomy.io<mailto:taylor@learningeconomy.io>>, chris purifoy <chris@learningeconomy.io<mailto:chris@learningeconomy.io>>, public-vc-edu@w3.org<mailto:public-vc-edu@w3.org> <public-vc-edu@w3.org<mailto:public-vc-edu@w3.org>>
Subject: Re: Wallet segmentation question for our LER Ecosystem SmartReport
Several of the “On Platform…” are Open Badges 3.0. Just something to consider.

On Jan 6, 2025, at 10:20 AM, Kerri Lemoie <klemoie@mit.edu<mailto:klemoie@mit.edu>> wrote:

Hi Manu,

re: “Wallet may be a tricky/misused term in edu but adding in a new term with the risk of legitimizing the principles of VCs, doesn’t seem like a great move to me.”

I’ll provide some more context to explain the above: In edu there are web apps that are called “wallets” that aren’t VC wallets. It’s been a struggle to explain the differences between those centralized apps and VC wallets and the differences between hosted and portable digital credentials. This has contributed to a learning curve but we’ve started making progress in the differentiation especially because Open Badges 3.0 is final and those apps are starting to adapt.

My statement above was addressing the term “wallet” that is already misunderstood/misused and another term called “On Platform Credential Management Tools” adds further complexity because then we have backpacks, centralized wallets, decentralized wallets, and then On Platform Credential Management Tools too. It adds to the confusion that already exists.

Ian, in discussions you & I have had, you mentioned that some of the feedback you’ve received outside of this thread is to not explain the difference between Open Badges 2.0 & 3.0 but I don’t see how you can avoid that because “On Platform Credential Management Tools” seems to equal Open Badges 2.0. So how about just calling them Open Badges 2.0 platforms? It’s a little bit of a simplification because some of these platforms are starting to offer 3.0 on top of 2.0 but next year, it will look different and that could be addressed then.

Manu – I 100% agree with your comments about vendor lock. And also concerned about closed ecosystems using SD-JWT VC and claiming to be VCs – we have those developing in edu too.

What I’ve noticed in edu is that portability and privacy is challenging existing business models (vendor lock)– and totally get that. But from my perspective (and the DCC’s), this is the paradigm shift we are working towards. It would be better if we can transparently explain the state of the ecosystem including the technical ramifications so that we can address them versus avoiding them and explore sustainability and profitability.

(Adding vc-edu mailing list back to this thread).

Thanks,

K.


From: Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>
Date: Monday, January 6, 2025 at 9:52 AM
To: Kerri Lemoie <klemoie@mit.edu<mailto:klemoie@mit.edu>>
Cc: Ian Davidson <ian@idatafy.com<mailto:ian@idatafy.com>>, Deb Everhart <deverhart@credentialengine.org<mailto:deverhart@credentialengine.org>>, Nate Otto <nate@ottonomy.net<mailto:nate@ottonomy.net>>, Phillip D. Long <phil@rhzconsulting.com<mailto:phil@rhzconsulting.com>>, Kate Giovacchini <kate.giovacchini@asu.edu<mailto:kate.giovacchini@asu.edu>>, Taylor Kendal <taylor@learningeconomy.io<mailto:taylor@learningeconomy.io>>, chris purifoy <chris@learningeconomy.io<mailto:chris@learningeconomy.io>>
Subject: Re: Wallet segmentation question for our LER Ecosystem SmartReport
On Mon, Jan 6, 2025 at 9:43 AM Kerri Lemoie <klemoie@mit.edu<mailto:klemoie@mit.edu>> wrote:
> I have critical questions about issuing platforms serving “On Platform Credential Management Tools”: What about learner privacy, the concept of not phoning home, and access to credentials (portability)? These are the foundational principle of W3C Verifiable Credentials and the work of VC-EDU.

Hmm, that's a great point Kerri. I had presumed that the "On Platform
Credential Management Tools" allowed for full portability and fought
back against vendor lock. If they don't, that's a critical difference
to point out. I have seen organizations using VCs and mDL in
vendor-lock settings and that is harmful to the ecosystem long-term.
If we end up just creating another vendor-lock ecosystem, we've lost
one of the biggest benefits of VC's data portability goals.

> Why bother with Open Badges 3.0 if they are going to be stored and tracked just like old badges? Are we saying that “On Platform Credential Management Tools” are not issuing VCs/Open Badges 3.0? If so, let’s just call that out so that the community understands what the differences are in functionality and approaches to trustworthiness.

The other concern that is in the back of my mind is the re-purposing
of the VC branding to promote closed ecosystem solutions. For example,
SD-JWT VC is definitely NOT a W3C VC, but that community has (somewhat
successfully) repurposed the brand name to sell closed ecosystem
solutions.

> Wallet may be a tricky/misused term in edu but adding in a new term with the risk of legitimizing the principles of VCs, doesn’t seem like a great move to me.

I don't quite understand the comment above. Do you mean that we could
further confuse things by adding yet another term? Or do you mean that
we could legitimize vendor-lock and tracking by opening up the
definition? For example, we allowed fully centralized DID Methods in
the DID Method registry and (rightly) drew criticism for doing so.

-- manu

--
Manu Sporny - https://www.linkedin.com/in/manusporny/

Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/




--
Ian Davidson
Chief Growth Officer, iDatafy
213.359.3109
ian@idatafy.com<mailto:dave@idatafy.com>
SmartResume.com<http://smartresume.com/>

Error! Filename not specified.calendly.com/ian-idatafy<https://calendly.com/ian-idatafy>