Simplify how Skill Assertions work by reusing the Achievement class

[ottonomy]

Follow-up from this morning's CLR/OB combined meeting. On the call, we noted that the rejection of trying to solve for #451 in the scope of this spec (in order to more closely rely only on VC-level verification capabilities commonly implemented among wallets and VC verifier services) means that there isn't a reason not to use Achievement for the "Skill Assertion" use cases that we had previously proposed using Result.alignment to cover. I was asked to take on an action item to work up a change proposal to the spec that would show how to accomplish Skill Assertion using the simpler already-built-in mechanism of Achievement.

Summary of suggested changes:

• Change overview sections that describe achievement assertions and skill assertions to indicate that Achievements may be created by a separate entity from the issuer, but that if a separate creator is not specified, assume the achievement is associated with the credential issuer.
• Clarify how verifiers should handle achievements in understanding their authorship, in that while third party issuing is enabled, trust in a particular issuer to make a particular claim fit for purpose of a verifier is up to the verifier.
• Update examples:
  • basicOpenBadgeCredential: Add an Achievement, because we no longer have a use case where there is not an Achievement.
  • skillAssertionCase: Update example to use Achievement rather than Result.
  • skillAssertionCtdl: Update example to use Achievement rather than Result.
• Update common_credentials.lines: As we no longer have a use case for an AchievementCredential where there is no achievement, updated the CredentialSubject class to specify that there must be exactly 1 achievement (from [0..1]).

Needs follow-up action if/when merged: update common data models and imported json-schemas to match required CredentialSubject.achievement property.

After doing this work, I do not think that we need to remove creator from the Achievement class as proposed by #457 in order to carry on from here without biting off the enormous potential scope of #451 or removing Achievement.id as proposed in #428. I think the above clarifications make it clear what the trust model should be when issuer and Achievement.creator differ and that this is a use case we can support for now. I hope this resolves the ambiguity that @kayaelle had supposed might exist in the spec if we allowed for issuer/creator difference without a mechanism for verification of creator-approved delegated issuance (which we will punt til later).

[justinpitcher]

Group discussed and approved, while opting to drop PR 457

[mgylling]

As per decision on WG call 2022-07-14, merging this PR.