Only carry endorsements at the top level

[amiller-ims]

In OB 2.0 Endorsements can target any entity. Examples are provided for Profiles (e.g. issuer), BadgeClass, and Assertion.

In CLR 1.0 Endorsements can ONLY target Profiles, Achievements (nee BadgeClasses), Assertions, and Clrs. And those 4 class data models defined an endorsements property which allowed them to carry their endorsements when they were re-used in another Clr.

OB 3.0/CLR 2.0 data models emulate CLR 1.0: Profile, Achievement, AchievementCredential, and ClrCredential all have an endorsement property which holds the endorsements that target that entity.

I propose we revert to the OB 2.0 style:

• Only the ClrCredential and AchievementCredential classes have an endorsement property
• The EndorsementCredential's credentialSubject can target any entity (including any Profile, Achievement, AchievementCredential, and ClrCredential)
• The verifier can find relevant endorsements by comparing the entity id to the credentialSubject.id

This is a simpler model to describe and implement.

[danblickensderfer]

Follow up with Phil Long [email protected] -- Marty Reed will contact Phil for his use of this @longpd

John Kuo: ASU Pocket intends to implement Endorsements

Use case (Marty): teaching license credential can have one or many endorsements, as well as at the "top" level of the CLR

[ottonomy]

I support this change in general, though I think we could trim it down to just ClrCredential, because of a "chicken and egg problem".

The endorsement won't know the id of an AchievmentCredential to endorse unless the AchievementCredential is created first, but if the AchievementCredential is created first, it wouldn't be able to include the endorsement anyway (unless reissued, which is fine). Dmitri brought up alternative use case that makes great sense within ClrCredential, which is that the endorsements contained there could be packaged endorsements that apply to other objects within the CLR that are known to the publisher/issuer of the CLR.

Something we could do here would be to include the endorsements property within ClrCredential only and advertise that the ClrCredential is a means of packaging endorsements that apply to sub-objects within. Then we can see what usage is like and follow up from there. I don't have any objections to just continuing with Andy's proposal to also include AchievementCredential in possibly endorsed scope. We can make a call on that before final status.

[danblickensderfer]

Reference July 7th meeting: workgroup decided to remove candidate final label, relabel as final and resolve for Final