Re: Wallet segmentation question for our LER Ecosystem SmartReport

A VC-101 is a timely idea.  I would encourage VC-EDU to extend the EDU framing and consider this in the context of lifelong learning. I know many have and are well aware of this issue. Yet, it needs rethinking beyond its current pattern.  

We need to seriously attend to the transition from the 3-phase life thinking (education, work, retirement) to a perspective that recognizes expected lifespans are now approaching 100 yrs. The implications of this are profound. They range from thinking about healthcare that aligns one’s healthspan to one’s lifespan, to considering learning and education as episodic engagements in formal learning activities interspersed with continuous informal learning. 

Both of these categories are enriched by and documented with verifiable credentials, and both can be issued by formal learning providers and by ourselves, strengthened by third-party affirmations. And all of this is couched in the expectation that formal issuers will come and go. The only constant is us. 

Systems and architectures that support and enable us to navigate these changing times are crucial. Let’s not forget that dependencies involved in different credentialing approaches. We should be seeking to minimize those with down sides that carry risks, and maximize those which have benefits throughout and across our learning, working and re-creating journeys. 

Cheers,
  Phil

> On Jan 9, 2025, at 6:13 AM, Doug Belshaw <doug@weareopen.coop> wrote:
> 
> Been following this with interest but with nothing much to add. Popping up to say that VC 101 would be welcome on https://badge.wiki <https://badge.wiki/> as a temporary home :)
> 
> On Thu, 9 Jan 2025 at 10:47, Simone Ravaioli <simone.ravaioli@parchment.com <mailto:simone.ravaioli@parchment.com>> wrote:
>> This is a juicy thread - we should try to distill and nurture the themes/nutrients properly. Thanks all for contributing !
>> 
>> @Sharon Leu <mailto:sleu@jff.org> appreciate you and JFF grounding us back into reality with emphasizing the segments of the populations we sometimes lose focus of.  Universal access - including working on Airplane mode - feels like a foundational property of Sovereignty.  We often get bogged down in Portability and Ownership, but I would say that Access is "Layer 0" of the SSI-stack. 
>> 
>> The functional requirements you are working on will be very interesting to share, once you are ready to!
>> 
>> On Monday we are taking this thread into a synchronous format of exchange. We have asked Ian to summarize the insights from the thread so far, informed and triggered by the research for the SmartReport - and continue the discussion. That is the basic agenda for the call at this point.
>> 
>> One of the goals, for me, would be to identify emergent themes that we can address separately.  For example, ensuring Open Badges 3.0 and "On-Platform Credential Management Tools" truly align with VC principles like portability and learner control is one.  
>> A corollary theme is going beyond the US and beyond OB3 - for example, European Digital Credentials.
>> I expect this to be a generative call giving us agenda items for weeks to come
>> 
>> A VC 101 is absolutely a resource that should be available to this community and also a more specific EDU version of it. I think we should collectively work on it and we as Chairs will take a lead (anyone willing to contribute step forward please).
>> That said, I would rather kick off Monday's call right away on the topic of "Wallet Segmentation and Credentials Management" as a primer.  With this being such a last minute focus, I expect that most people showing up would be the usual aficionados. 
>> 
>> Once the VC 101 is available we can use it at scale  (here is a quick draft  <https://www.perplexity.ai/page/verifiable-credentials-101-foc-2VQfr1YITcux_PxCSq6C_g>generated with Perplexity) - thanks again for the suggestion !
>> 
>> Look for the standard meeting invitation with agenda email soon. 
>> 
>> Simone
>> 
>> On Tue, Jan 7, 2025 at 5:23 PM Sharon Leu <sleu@jff.org <mailto:sleu@jff.org>> wrote:
>>> Hi all,
>>> 
>>>  
>>> 
>>> This thread is very timely and exciting for team JFF, who have been working on the official update to the market scan that we published a few years ago (jff.org/digitalwallets <http://jff.org/digitalwallets>).  We’ve also been wrestling with a number of issues related to our approach to describing this growing ecosystem and the various technology developments that have occurred and are on the horizon. 
>>> 
>>>  
>>> 
>>> As with our 2022 publication, we again approach wallets as the critical nexus that enables all individuals to pursue whatever opportunities they need or desire.  We again double down on our opportunities for impact and attempt to clearly describe the conditions we consider to be sufficient or necessary, vs those that are desirable for other reasons.  To Kerri’s earlier comment, we make these distinctions by refocusing attention on the functional requirements that enable a variety of use cases for those users who we believe are underrepresented, underserved, and/or otherwise excluded from participation in the workforce and their communities, aka the “JFF North Star Populations”.  Even though we are still in the early stages of draft development, I believe that we will not likely be using the many classifications discussed in this thread unless they occur within context or relation to our functional requirements for these populations. 
>>> 
>>>  
>>> 
>>> For example, we have always considered the portability of credentials and privacy of data to foundational components of an ecosystem that would best serve our users, so strongly support iterations towards open ecosystems that enable agency.  Per the approach we have taken with the plugfests, we strongly support those applications (or if you want to delineate, wallets or credential management platforms) to demonstrate interoperability, rather than standards conformance, which as Simone notes, are definitely not the same thing, for OB or otherwise.
>>> 
>>>  
>>> 
>>> Simone – you mentioned this would be the discussion topic for next Monday’s call.  Is there a specific agenda of topics?  Seems this thread has spanned a number of critical topics relevant to this task force and it would be good to identify the goals of the discussion so that we can make collective progress.  Since it is a discussion that will occur within the context of this W3C group, I wonder whether co-chairs might consider a quick 101 on the VC standard, since the group will have newer participants who might be confused about what are VCs and DIDs, SSI, and other related defined terms.  That might reduce the amount of interpretation of novel terminology such as “VC principles” which are confusing and distracting.
>>> 
>>>  
>>> 
>>> Look forward to connecting with everyone again soon!
>>> 
>>>  
>>> 
>>> Sharon
>>> 
>>>  
>>> 
>>>  
>>> 
>>> From: Ian Davidson <ian@idatafy.com <mailto:ian@idatafy.com>>
>>> Date: Tuesday, January 7, 2025 at 10:21 AM
>>> To: Kerri Lemoie <klemoie@mit.edu <mailto:klemoie@mit.edu>>
>>> Cc: Phillip D. Long <phil@rhzconsulting.com <mailto:phil@rhzconsulting.com>>, Simone Ravaioli <simone.ravaioli@parchment.com <mailto:simone.ravaioli@parchment.com>>, 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>>, 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
>>> 
>>> Phil,
>>> 
>>>  
>>> 
>>> I agree!  In fact Rob Coyle was the first person I spoke with to suggest that the wallet category needed to be segmented for this exact reason which is what kicked off the research into the various segments of what we're now calling credential management.  That's why we have the self-sovereign segment - to recognize those wallets that are designed for maximum credential holder control.
>>> 
>>>  
>>> 
>>> This has been a helpful exercise and I hope to join the call next week. Can someone please add me to the invite?
>>> 
>>>  
>>> 
>>> Here are dimensions that I believe (just my opinion) can be used to segment different types of credential management tools:
>>> 
>>>  
>>> 
>>> 1.  Public access vs. target audience access: Is this a tool only available to residents of CA with a driver's license?  Or can it be used by anyone who can download it from an app store?
>>> 
>>> 2.  Self-Sovereign Design vs. Issuer Feedback Loops: Is this designed to maximize the holder's privacy over how they use their credentials, or is it designed so Issuers's get feedback on how their credentials are used? This seems to be a somewhat divisive conversation but based on the conversations I had with stakeholders over the last couple of weeks there are arguments for both sides and the reality is there will be lots of hybrid approaches along this spectrum.
>>> 
>>> 3. Curated vs Uncuratated user experiences: Some wallets are designed for storage and portability with limited design elements to support specific user experiences or use cases.  Others are designed for a highly curated use case.  (Learner Credential Wallet vs. Indiana Achievement Wallet is an example)
>>> 
>>> 4. Internet Connectivity Reliance: As Kate said, "Does it work in airplane mode?"
>>> 
>>> 5. Decentralized vs. centralized identity: Many users want to manage and control their identity, but we must recognize that many other users are fine with Google or Apple or another identity service managing their identity.  
>>> 
>>> 6. Credential importation capabilities: This is less of a spectrum and more about the options that are available and how many a credential management tool includes. From what I've seen through different existing tools the current capability set includes: manual user upload, JSON code upload, wallet linkage, and API integrations.
>>> 
>>>  
>>> 
>>> I heard back from several "on-platform credential management tool" platforms yesterday and my big takeaway is that there are so many elements here that aren't black and white.  For example, one platform said they'll enable any user to download any credential as an OB3. But those OB3s still include a link back to the credential issuing platform per the guidance of the OB3 spec (their words).  Other platforms said they would soon enable users to move OB3s into wallets directly from the issuing platform.  It seems close to impossible to segment the market based on these dimensions.  Every credential management tool will make design and tradeoff decisions based on dimensions like these meaning clean categorization will remain elusive.  But I do believe we gain by making the attempt and presenting the information in a way that is not overly precise but still shows the variety of tools available to those who wish to implement their LER strategy.
>>> 
>>>  
>>> 
>>> I've tweaked the definitions to attempt to do this the best I can.  Here are the updates:
>>> 
>>>  
>>> 
>>> Self-Sovereign Credential Wallets - These credential wallets embed credentials on a personal device (usually a smart phone), make them accessible without internet access, and share and verify credentials using the W3C Verifiable Credentials standard. The wallet is detached from any credential-issuing platforms, is controlled by the user, and is available to the general public.
>>> Consumer Brand Services Wallets - These credential wallets focus on delivering a curated set of capabilities or user experiences designed to serve a specific audience of credential holders. They may be mobile-app or web-based but are always wrapped in a specific consumer brand and are designed to include or integrate a specific set of services on top of the storage of credentials. For example, some of the credential wallets in this category include or integrate services to offer career path advice, provide data on jobs and careers, and recommend learning opportunities.
>>> White Label Wallet Tech Developers - These companies help consumer brands develop Consumer Brand Services Wallets by defining a desired user experience for how the credentials will be utliized and what services will be provided to individual users and then developing that consumer experience. They provide the underlying technology and maintain that technology over time on behalf of the consumer brand customer.
>>> 4. On Platform Credential Management Tools - LER platforms that include credential-sharing tools embedded directly into the platform to move credentials into other LER platforms or credential wallets or through links or APIs into common websites like LinkedIn or Facebook. These tools are web-based and do not meet the criteria of self-sovereign credential wallets, but they may enable users to export their LER data to credential wallets as portable assets (both self-sovereign and web-based). These credential management tools vary in their ability to import/sync/store credentials issued from other platforms to enable users to curate a comprehensive set of LER data.
>>> 
>>>  
>>> 
>>> - Ian
>>> 
>>>  
>>> 
>>> On Tue, Jan 7, 2025 at 8:33 AM Kerri Lemoie <klemoie@mit.edu <mailto:klemoie@mit.edu>> wrote:
>>> 
>>> 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 <mailto:phil@rhzconsulting.com>>
>>> Date: Monday, January 6, 2025 at 7:50 PM
>>> To: Simone Ravaioli <simone.ravaioli@parchment.com <mailto:simone.ravaioli@parchment.com>>
>>> Cc: Kerri Lemoie <klemoie@mit.edu <mailto:klemoie@mit.edu>>, Ian Davidson <ian@idatafy.com <mailto:ian@idatafy.com>>, 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>>, 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
>>> 
>>> 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 <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 <mailto: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>
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>> 
>>> 
>>>  
>>> 
>>> --
>>> 
>>> Ian Davidson
>>> 
>>> Chief Growth Officer, iDatafy
>>> 
>>> 213.359.3109
>>> 
>>> ian@idatafy.com <mailto:dave@idatafy.com>
>>> SmartResume.com <http://smartresume.com/>
>>>  
>>> 
>>> calendly.com/ian-idatafy <https://calendly.com/ian-idatafy>
>>>  
>>> 
>>>  
>>> 
> 
> 
> 
> --
> Dr. Doug Belshaw
> Founding member, We Are Open Co-op <https://weareopen.coop/>
> 📱 +44 (0)7791 993175
>  🏡 dougbelshaw.com <http://dougbelshaw.com/>
> 
> Check out Learn with WAO <https://learnwith.weareopen.coop/> for our podcast, free email-based courses, and openly-licensed resources!