Re: Support for Verifiable Claims

Great and timely thread. Apologies in advance for a reply that will not meet your requests for brevity, though hopefully it does advance the clarity of how there are good chances for the VCTF proposals to be enacted in the market.

One use in consideration for the proposed data model and specification supports the work of Open Badges. Open Badges has been operating under the Badge Alliance since 2014 after graduation from incubation in the Mozilla Foundation. I've been serving as director of the Badge Alliance and the badges community's representative to the VCTF and Credentials Community Group.

We've just announced that Open Badges will become an IMS Global specification as of January 2017. See press release:

IMS Global, Mozilla Foundation and LRNG Announce Next Steps to Accelerate the Evolution of the Open Badges Standard https://www.imsglobal.org/article/ims-global-mozilla-foundation-and-lrng-announce-next-steps-accelerate-evolution-open-badges <https://www.imsglobal.org/article/ims-global-mozilla-foundation-and-lrng-announce-next-steps-accelerate-evolution-open-badges>

IMS has good experience in the higher ed and broader education marketplace, but they have submitted a letter of support for a Verifiable Claims Working Group at the W3C as well, seeing a good chance for compatibility between these efforts.

> That’s why several of us have been pressing for a clear explanation of how this proposal fits into existing ecosystems, exactly how a W3C data model and syntax could compose with existing APIs and protocols, and how the community that hopes to work at W3C can get the standards deployed in the real world.


Here are some notes on how this proposed standardization effort may mesh with the Open Badges work. There are millions of awarded Open Badges and an ecosystem of thousands of issuers using dozens of different applications that implement the Open Badges specification. See http://openbadges.org <http://openbadges.org/>

Even with such broad deployment, there are major improvements needed to the specification, and the sooner we can get to stability of complementary/possible dependency specifications, the easier it will be for us to rely on them to perform key functions in our ecosystem. While many implementers of Open Badges are fine moving forward while this work is still being incubated (indeed helping incubation through our work), I think if the VCTF effort moves toward standardization, it would improve the stability of Open Badges and our ability to improve some weak points in our spec.

IMS will lead the Open Badges Working Group to refine the OB data model for Issuer Profile, BadgeClass and Assertion data classes. An Open Badge at present is made up of an Assertion that references a BadgeClass that references an Issuer Profile. These are Linked Data classes that will have to interoperate with a number of other specifications, formal and not, especially around definitions of Competencies used to connect higher ed market with workforce.

While Open Badges currently make sense for recognizing defined achievements for recipients who are identified by email addresses, there is a need to verify through trusted parties that a particular Issuer Profile actually represents the organization or individual it describes. For this, community members have suggested defining a method for Endorsement using the VCTF's data model to make any additional claims about the entity that is the recipient of the endorsement. The proposed VCTF data model fits very nicely within our prototypes of an endorsement, which is essentially an Open Badge without a BadgeClass (defined achievement) component. Open Badges as we currently understand them are Endorsement claims of a specific achievement. Endorsement with verifiable claims solves important use cases among our implementers, and we have a number of companies ready to invest in deploying them.. Additionally, while procedures to verify Open Badges through "hosted" verification or cryptographic signing are currently under the purview of the Open Badges Specification, it may be nice in the future to be able to factor out this effort to a generalized specification for verification of any "claim", such as is proposed through the VCTF charter.

More importantly, I think that use of Verifiable Claims within Open Badges software provides a road to broad deployment that does not require broad deployment to be initially useful. We have problems to solve that the small use cases identified in the charter can work on. We can start there and work up to the very complex desires of some of the VCTF members gradually.

>I am asking for someone to explain what the path from data model to real world  distributed identity / claims system looks like.


I am seeing a lot of companies and educational institutions investing in the idea of Open Badges, and I want to make sure their investment is productive if I can. The learners who are given Open Badges to recognize their achievements suffer if their investment in education leaves them with vaporware credentials.

A couple problems we can work on with more confidence if we can rely on the VCTF model:
* Vendor lock-in/portability of accounts between vendors
* Updating badges to handle changes to recipient email addresses

Vendor lock-in: Right now, there is some vendor lock-in built into the Open Badges spec, because much of the moving parts rely on HTTP URI-hosted resources, referencing each other by those HTTP URIs. Our issuer users would like to have the ability to move from platform to platform without losing the trust connections and endorsements their Issuer Profiles will have received. The VCTF deliverables look to me to be a promising part of how we could enable that goal in the short term, and we could use this to try out models of how we can build a global and equitable distributed identity system without making strong assumptions that we know the exact path there too early.

Updating email addresses: An example of how Verifiable Claims could be effective in the badges ecosystem even without a huge VC-based service ecosystem is in how badges currently reference recipients through email addresses. A Verifiable Claim made by the original issuer of a set of badges to someone's university email address that the recipient may also be known by a personal address after they have graduated would be a good-enough trust signal to keep those badges useful even after the recipient has lost the ability to verify their previous email address. We can work our way from email addresses to other identifiers that make more sense for future use cases, perhaps that rely on blockchains or other distributed non-DNS-based schemes.

Additionally, we need something like verifiable claims to make it possible to robustly use Open Badges with under-13 recipients in the US, where no personally identifiable information may be included in the badge. A set of badges issued to an "opaque" identifier followed up with a Verifiable Claims-based endorsement that the opaque identifier may be interpreted to correspond to a certain user profile for someone who is now 13 would fit the bill. In fact, while some of our other endorsement use cases would be possible without the VC work, this one requires it or something almost identical to it.

I don't think we need to have the full browser API, distributed identifier resolution system, and the rest of the ecosystem some are envisioning to be in force before we can start getting real gains from the VCTF proposed work in the Open Badges community..

> This is probably the crux of the disagreement on this thread:  Should  W3C  start by building standards and recruit implementers to make it a marketplace reality, or should W3C provide a venue where implementers and other players in real markets collaborate to iron out their differences to improve interoperability, accessibility, security, etc.?  I submit (and I think Chris and Tantek agree) that the former approach might have been successful in the early days of W3C, but there are few successful examples of a standards-first approach in recent years.  That’s why we push for incubation-first - -build communities, get rough consensus and running code first, then standardize what is successful.



> If there is rough consensus and running code around the proposed verifiable claims data model already, then I for one just need a clearer and more succinct guide to it than what the WG proposal offers.


You're right with the link to the XKCD comic that many decisions about specific implementations are essentially arbitrary and there may be many "right" solutions. However, I'm seeing a problem with a lack of standardization in the higher ed/workforce market around Competency description language that makes me want this effort to move forward. There are a large number of competing ideas with varying requirements for what makes up a Competency and its relationships with other data. Developers don't know which horses to back. If there were a respected standards body that took up that conversation, we'd be able to more easily build support around that being a venue where these decisions could be hashed out, where we could tell developers to look for a community that wanted to build an interoperable solution.

Yes, it makes sense to decide that there should be a tipping point around rough consensus that should be achieved before beginning standardization work that limits flexibility. On the other hand, there is risk to setting that bar too high, because it's very useful to have a signal that a specific standards body is a ready and appropriate venue for organizations to solve these problems together. In the absence of that, we risk some more disorganization and accidental fragmentation of efforts like I've seen in the Competency description language space.

I support this proposal being taken seriously at the W3C, and I think representatives of the badges community have a rough consensus that these ideas, especially as they enable our proposed concept of Endorsement, should move forward. We can operate via IMS Global without the formation of a W3C group, but our efforts would be empowered if the W3C took this on as part of its official work.


Nate Otto
Director of Technology, Badge Alliance
badgealliance.org <http://badgealliance.org/>