Re: EOCred: recognition of credential

On Tuesday, May 22, 2018, Phil Barker <phil.barker@pjjk.co.uk> wrote:

> Thank you Nate. I understand your reluctance to accept unverified
> statements of recognition for your use cases and appreciate your agreement
> not to block their use for other cases (where I think verification can be
> by other means).
>
> I don't think here is the right place to go into details of how our
> proposal would work with any future development of verifiable endorsements,
> but I think there are a couple of options: either using a pattern similar
> to that shown <http://blog.schema.org/2014/06/introducing-role.html> by
> Role <http://schema.org/Role> where an intermediate schema.org type can
> provide additional information about a relationship (the AlignmentObject
> does something like this too), or by creating new verifiedRecognition
> property. I am confident therefore that having recognizedBy as a property
> won't prejudice any future efforts to verify such a claim.
>
I originally had Credential and CredentialInstance (with issuer and issuee
properties). It was then proposed that a ConferAction schema.org/Action
should be created in order to reify the relation.

AFAIU, the scope of this WG specifically excluded linking between
individuals and instances of credentials.

W3C Verifiable claims has a multi-step workflow which is more correct than
adding ConferAction and RevokeAction someday, IIUC.

Actions: Issue, Assert, Verify, Store/Move, Retrieve, Revoke

Most existing claims (such as on a social network profile or an resume) are
not yet verifiable: we can accept them at face value only and there may
never be any way to issue cryptographically-signed verifications from
entities capable of securing a private/public keypair.

While existing professional and academic social networks do allow
unverified claims regarding Credentials (and any other fact but email
address), we might shouldn't even make it possible to express such a
relation without e.g. W3C Verifiable Claims.

> Regards, Phil.
>
> On 22/05/18 15:49, Nate Otto wrote:
>
> For me, the verifiable endorsements are the only type of recognition that
> I would trust. I won't block the inclusion of recognizedBy, but structuring
> the relationship as RecognizedEntity.recognizedBy -> RecognizingEntity
> doesn't allow for the relationship to flow through a specific verifiable
> record describing that recognition. I think the
> RecognizedEntity.endorsements -> Endorsement -> Endorsement.issuer ->
> RecognizingEntity allows us to describe the scope or purpose the credential
> or other entity is recognized for.
>
> Nate Otto
> Director, Open Badges, Concentric Sky
> concentricsky.com
> he/him/his
>
>
> --
>
> Phil Barker <http://people.pjjk.net/phil>. http://people.pjjk.net/phil
> PJJK Limited <https://www.pjjk.co.uk>: technology to enhance learning;
> information systems for education.
> CETIS LLP <https://www.cetis.org.uk>: a cooperative consultancy for
> innovation in education technology.
>
> PJJK Limited is registered in Scotland as a private limited company,
> number SC569282.
> CETIS is a co-operative limited liability partnership, registered in
> England number OC399090
>