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:


   1.

   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.
   2.

   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.
   3.

   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> 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>
> *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
> 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,
>
> *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> 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>
> *Date: *Monday, January 6, 2025 at 11:31 AM
> *To: *Kerri Lemoie <klemoie@mit.edu>
> *Cc: *Rob Coyle <rcoyle@1edtech.org>, Manu Sporny <
> msporny@digitalbazaar.com>, Deb Everhart <deverhart@credentialengine.org>,
> Nate Otto <nate@ottonomy.net>, Phillip D. Long <phil@rhzconsulting.com>,
> 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
>
> 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> 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,
> *Date: *Monday, January 6, 2025 at 10:41 AM
> *To: *Kerri Lemoie <klemoie@mit.edu>
> *Cc: *Manu Sporny <msporny@digitalbazaar.com>, Ian Davidson <
> ian@idatafy.com>, Deb Everhart <deverhart@credentialengine.org>, Nate
> Otto <nate@ottonomy.net>, Phillip D. Long <phil@rhzconsulting.com>, 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
>
> 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> 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>
> *Date: *Monday, January 6, 2025 at 9:52 AM
> *To: *Kerri Lemoie <klemoie@mit.edu>
> *Cc: *Ian Davidson <ian@idatafy.com>, Deb Everhart <
> deverhart@credentialengine.org>, Nate Otto <nate@ottonomy.net>, Phillip
> D. Long <phil@rhzconsulting.com>, Kate Giovacchini <
> kate.giovacchini@asu.edu>, Taylor Kendal <taylor@learningeconomy.io>,
> chris purifoy <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> 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 <dave@idatafy.com>
>
> SmartResume.com <http://smartresume.com/>
>
>
>
> *Error! Filename not specified.*calendly.com/ian-idatafy
>
>
>
>
>
>
>


-- 
Ian Davidson
Chief Growth Officer, iDatafy
213.359.3109
ian@idatafy.com <dave@idatafy.com>
SmartResume.com

calendly.com/ian-idatafy