or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
![image alt](https:// "title") | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Syncing
xxxxxxxxxx
Peer Claims with Open Badges and Verifiable Credentials.
by Nate Otto, Kim Hamilton Duffy, and Kerri Lemoie
Contributors:
Licensed CC-BY. The authors of this document commit to sign and abide by the W3C Community Group IPR Policy to facilitate this work being used in the web standards process.
Abstract
Peer Claims, or Peer Endorsements, are a type of Open Badges Assertion with an emphasis on light reusable credential descriptions to be awarded by many different issuers. We will describe this notion of peer claims using capabilities defined in the [Open Badges are Verifiable Claims paper](TODO: link) for Rebooting Web of Trust 6. This paper will inform the development of proofs of concept for peer claims use cases. We will then analyze the new capabilities and required updates relative to Open Badges software in the roles of Issuer, Host/Backpack, Displayer and Validator.
Table of Contents
Introduction
Peer Claims are what members of a community use to recognize one another. Assertions of these claims are Open Badges Assertions of a particular BadgeClass made by one or more entities who are peers of one another. A peer claims ecosystem may be bootstrapped by a privileged BadgeClass creator, in which the creator establishes the capability for peers to award Assertions. However, the peer claims ecosystem is not governed by centralized authorities.
In a companion paper, Open Badges are Verifiable Claims, developed for the Rebooting Web of Trust workshop in Spring 2018, examples were presented showing Open Badges Assertions delivered using the Verifiable Credentials Data Model. This paper extends that work to illustrate a method of making lightweight claims for peers to recognize one another.
Use Cases
Publish BadgeClass available with universal Award capability
As an Issuer, I would like to grant a capability to anybody to Award an instance of a BadgeClass I publish. As part of a competency recognition program in their institution, the issuer would like to publish a 21st Century Skills framework with associated BadgeClasses that may be awarded by anybody in recognition of a peer claim.
Publish an Assertion of a open-award BadgeClass as a peer endorsement of another entity.
Students will be able to award each other Endorsements that assert competence in one of the elements of the institution's framework with a little narrative about the award. These Endorsements will be Verifiable Claims asserting other students hold the institution-defined BadgeClasses with narratives describing what they had done to demonstrate the competency. Their proofs should invoke the capability granted by an issuer.
Grant a capability to anyone who holds a particular BadgeClass award
As an Issuer, I would like to allow anybody who holds the BadgeClass to award it to anybody else. I can grant a capability to anyone, but attenuated to only those who hold a valid Assertion of the BadgeClass to be awarded. (This works to identify any BadgeClass as the prerequisite, not just the specific one to be awarded.)
Multiple peers publish an Assertion of a minimal ad-hoc BadgeClass that can be related by other properties than a resolvable ID
Issuers and consumers/inspectors/verifiers of badge Assertions may wish to use concepts from BadgeClass without need for all the properties. For instance, the above competency framework use cases could be recast to use a BadgeClass made up of only an alignment:
Relaxing requirement list on BadgeClass, including removing
image
,criteria
, andissuer
makes it possible to publish and consume very targeted claims. However, there is some power in consistent implementation of the BadgeClass model, so "fully defined" implementations of BadgeClass, which may still be referenced by resolvable ID in Assertions, still have a strong purpose in the ecosystem.Publish an assertion for a credential defined in the Credential Engine Registry
The Credential Engine Registry (CER) is a database with open APIs that stores and shares metadata about credentials, credentialing organizations, quality assurance organizations, and competency frameworks. The Credential Transparency Description Language (CTDL) describes each credential and associated entities. Organizations publishing to the CER are human-verified prior to publishing credential data.
Each credential stored in the CER contains a unique resource link which returns a JSON payload of the credential's properties as required or reccomended by the CTDL. By referencing this resource link in an assertion the metadata for this credential is accessible as part of the verifiable credential. An example of a resource:
It is required that each credential contains at least an
ceterms:ownedBy
orceterms:offeredBy
property. A credential may contain multiples of each property. When the resource is linked to from an assertion,ceterms:ownedBy
orceterms:offeredBy
data may be the verified issuer(s) of a credential. While it can't be assumed thatceterms:ownedBy
is the "creator" of the credential. It is arguable that the organization(s) referenced in theceterms:ownedBy
property is the arbitrator of which organization(s) are referenced in theceterms:offeredBy
property.At this stage of CER, organizations are the main providers of the credentials. However, the CER has made accomodations for individuals to be providers as well.
Supporting Kirkpatrick Level 3 evaluation
The Kirkpatrick model of learning/training evaluation comprises four levels:
Level 1: Reaction — The degree to which participants find the training favorable, engaging and/or relevant to their jobs (usually referred to as the "smile sheet")
Level 2: Learning — The degree to which participants acquire the intended knowledge, skills, attitude, confidence and commitment
Level 3: Behavior — The degree to which participants apply what they learned during training when they are back on the job
Level 4: Results — The degree to which the training has an impact on the organisation's results, e.g. turnover
To support the transfer to the workplace of what participants have learned during a training intervention the suggestion is to have a verifiable claim with an embedded signature workflow:
This means that the VC is like a small automaton with 3 different states and the transition from one state to the next is triggered by the signature of one of the parties. This is a very specific use case linked to training, though the roles may be generalized to apply to a broader range as well. The role of the trainer here may be filled by any assessor, including any peer expert. The states are:
This simple workflow could be augmented by adding the signature of the HR department, or that of an awarding body, etc. The great advantage of this way of working is that it is the way we do when we use a simple sheet of paper signed by the different parties. Moreover, there is a whole literature on "learning contracts" that reports their benefits on learners' engagement.
This supposes a number of features that do not (yet) exist currently with Open Badges:
The solution using current badge systems would be to implement the workflow within badge issuing platforms, with 3 different assertions, ther first one being used as evidence of the next one. The idea with VC would be to embed the rules within the claim so it is independent from any kind of platform, but the simple ability of the parties to sign the claim in the right order.
When the badge is issued it contains a condition relative the three parties engaged into the workflow. The condition could be:
ID_Trainer owns credential "XWZ"
It also contains a rule for the signature order, so that if the line manager signs before the trainer, the badge is declared invalid (and the reputation of the line manager decreases!). We could also add a time condition, something like
ID_LineManager signature time > ID_Trainer signature time
. It would be the task of the verification to check that the badge is well formed according to the rules.The verification process could also be the process that replaces the image in which the claim is embedded as the worlflow progresses. Which means that the verification process should then sign the badge, so one would be able to verify the verifier.
Recommending someone for a credential
This is based on a real use case from the Université de Normandie. Students have the ability to recommend other students for a particular badge. They don't issue it, just make a recommendation that is later validated by a jury. The value of a recommendation is that it can be performed by someone who is not an expert in the domain, it is less engaging than the issuing of a badge and it involves the community of peers in the recommendation process. It can be read as a pre-endorsement of a particular credential or badge instance.
In the life cycle of a credential, recommendations and endorsements are at the two ends: recommendations are an invitation to issue a credential while endorsements is a confirmation of the merit of the credential's holder.
While an endorsement makes reference to two entities (the endorser and a BadgeClass, an assertion, or anything bearing an identifier) a recommendation makes reference to 3 entities: the recommender, the BadgeClass (with the issuer ID) and the recipient.
The difference between a recommendation and a regular credential is who is at the origin of the recognition cycle.
Skill Assessment & Recognition (bilan de compétences)
Marie wants to have her competencies in permaculture recognised. For that, after checking that it does not already exist, she creates a "permaculture professional" badge and signs it. She then collects evidence of her work into a portfolio and uses the link to the "permaculture portfolio" as evidence of her skills. In parallel she collects testimonies, testimonials and endorsements of her skills (people add their signatures to the badge created by Marie or to the evidence collected in the portfolio).
As Marie is in contact with other people involved in permaculture, she invites them to claim their own permaculture badges — "permaculture trainer," "permaculture supplies provider," "permaculture journalist," etc. To address the diversity of permaculture badges, she decides to create an overarching permaculture badge "permaculture community member" that everyone can claim—to be issued, the badge needs to be reviewed by 5 people who already have that badge.
As the community of practice grows, the leaders of the community ask for their badges to be endorsed (recognised) by the ministry of agriculture, the ministry of labour and ministry of education.
The products of the permaculture have their own badges eliciting their provenance and the value chain between producers, distributors and consumers.
Key elements in the use case
A badge is representative of a community and therefore it can be used to make a community visible (not just a skill). It is the community that gives credibility to the badge and then is in a position to ask for a formal recognition by public authorities. Global recognition starts with hyperlocal recognition.
It is therefore critical to associate badges with social/community spaces where badges are produced and consumed. "Permaculture Badges" are not just useful to elicit skills (the initial intention of Marie) but also as an attribute attached to the product/service produced by such skills. The permaculture badge ecosystem as an echo of the extended permaculture ecosystem.
Questions/Considerations
ceterms:ownedBy
andceterms:offeredBy
. Reference: CER Organization property CER resources may contain multiple values for these properties (confirm) whereas an open badge conatins a single issuer property.Scenarios (assuming Issuer property is in the assertion, not in the badge class and that the assertion links to a CER resource)
ceterms:OpenBadge
; CER resource contains a singleceterms:ownedBy
but notceterms:offeredBy
; Issuer property correlates withceterms:ownedBy
. BadgeClass is not present in the assertion.ceterms:OpenBadge
; CER resource contains a singleceterms:ownedBy
as well as a singleceterms:offeredBy
; Issuer property correlates withceterms:offeredBy
. BadgeClass is not present in the assertion.ceterms:OpenBadge
; CER resource contains multipleceterms:ownedBy
as well as a singleceterms:offeredBy
; Issuer property does not correlates withceterms:ownedBy
orceterms:offeredBy
. BadgeClass is not present in the assertion.ceterms:Certification
; CER resource contains a singleceterms:ownedBy
but notceterms:offeredBy
; Issuer property correlates withceterms:ownedBy
. BadgeClass is not present in the assertion.ceterms:Certification
; CER resource contains a singleceterms:ownedBy
but notceterms:offeredBy
; Issuer property correlates withceterms:ownedBy
. BadgeClass is present in the assertion.ceterms:OpenBadge
] (http://credreg.net/ctdl/terms#OpenBadge); CER resource contains a singleceterms:ownedBy
but notceterms:offeredBy
; Issuer property correlates withceterms:ownedBy
. BadgeClass is present in the assertion but the badge class description does not match the CER resourceceterms:description
](http://credreg.net/ctdl/terms#description ). Note that description is a required property for both badge class and CER.Examples
A BadgeClass with universal award capability grant
The BadgeClass may include a capability grant
A Peer Claim invoking universal award capability
A student could sign a very lightweight piece of data in order to make a lightweight claim about a peer. In this claim, they would invoke the capability granted by the issuer of the BadgeClass.
Alternately, if the granting capability were available the URI http://www.issuer.org/167fd864-9fa5-4669-828a-1f4964eeb207, the invocation could be expressed as linked data as follows:
In this example, three entities are identified just by a resolvable ID.
did:example:alice
resolves to the issuer's DID Document, which contains the signing key used in the proof.did:example:bob
resolves to the recipient's DID Document, which can be correlated with other claims issued and received by the entity who is the recipient of this award.https://example.com/freebadges/teamwork
resolves to a BadgeClass published by another creator.The BadgeClass or its issuer Profile DID Document would contain a capability grant using Linked Data Capabilities to grant to anyone (or anyone who holds a particular BadgeClass, for instance) the capability to award these peer assertions.
Example of a BadgeClass that may be awarded by anyone who holds it ("viral")
A BadgeClass might contain a capability grant like the example above, but attenuated with a caveat that the invoker of the capability must hold a certain BadgeClass.
This could be invoked by presenting evidence verifiable by an inspector to match the caveat in the Capability:
Alternately, if the granting capability were available the URI http://www.issuer.org/167fd864-9fa5-4669-828a-1f4964eeb207, the invocation could be expressed as linked data as follows:
TODO: Implementation User Stories for Open Badges software
Issuer
TODO: anything else required for issuers?
To support peer claims, the Issuer would define and host specifications for:
In the latter case, our example restricted that capability invocations must hold a claim with id "https://example.com/freebadges/teamwork". To do this, the issuer must ensure issued claims match the id in the hosted attenuated BadgeClass.
Host/Backpack
TODO: not sure
Displayer
TODO: not sure
Verifier
The Verifier ensures the capability is valid by following the steps defined in LD Capabilities Invocation.
To summarize that process, the Verifier ensures the claim contains a
proof
property where:proofPurpose
equalsinvokeCapability
capability
property links to the capability document or describes the capability inlineinvoker
, the child claim doesn't need to be signed with a parent's invoker field, so it only needs to be signed with a child keyThe Verifier must also ensure:
capability
document grants authority to invoke this capabilityinvocationTarget
's keysAt this point, the invocation is considered valid and any relevant action may be performed.
Notes:
invoker
field; if so, additional steps apply, as described in LD Capabilities Invocation.Next Steps
Contributors to this paper and their outside collaborators intend to build several prototypes that demonstrate proofs of the concepts discussed.
Peer Recognition Network Proof of Concept
Particularly, one system we are sketching out for development involves:
Parking Lot (meta notes for editors)
TODOs