Feature/vocab claim bugfix

[ottonomy]

Fixes one issue I noticed myself, one issue that @erickorb, @dlongley and @msporny noticed, and one issue that @elf-pavlik noted.

• claim is a property of a Credential. It's associated value must be a ClaimSet.
• The @type value in the context for claim must be @id, not ClaimSet -- @type is for datatypes of literal values, not class types of JSON object literals.
• Took example 2 (Credential) out of an ambiguous wrapper so it appears on its own. As embedded in an Identity document, it wouldn't have the context link in this spot, but when freestanding it would.

Thanks for feedback, all.

[erickorb]

I still think there's conflict on how "claim" is be used in the two contexts. I believe the use below, says that "This credential, of type badge, is claiming that https://foo.com/i/erickorb has achieved the following..."

{
  "@context": "https://w3id.org/openbadges/v1",
  "alignment": [],
  "claim": {
    "about": "https://foo.com/i/erickorb"
  },
  "criteria": [
    "https://foo.com/?badge=66&award=944"
  ],
  "description": "4th Grade Level Basic Writing Skills",
  "id": "https://foo.com/badges/1.1.41.c",
  "image": "https://foo.com/basicwritingskillsbadge.png",
  "issued": "2014-02-10T06:00:00Z",
  "issuer": "http://www.foo.com",
  "name": "4th Grade - Basic Writing Skills",
  "owner": "https://foo.com/i/erickorb",
   ...
  "type": "Badge"
}

[ottonomy]

Hmm, interesting.

As you pointed out on the call yesterday, there is a conflict with the term claim appearing in both the security context and the credentials context. However, even though that term is mapped to an IRI (https://w3id.org/security#claim) in the security context, there is not a corresponding entry in the security vocabulary for that term. Even so, we need to resolve that conflict, I assume by picking a different shorthand term name other than claim. Since claim isn't defined in the security vocabulary, I can't really form an opinion on whether the security vocab would be a suitable place for that term to live for use in a credentials context.

@erickorb @msporny: Are you of the opinion that https://w3id.org/openbadges/v1 should be in alignment with the current work? I thought the target for alignment was bringing together the Identity Credentials spec and the Open Badges spec. Eric, if the snippet you posted represents work that would use the "v1" context, then that context is not compatible with what we are trying to do in the Credentials Community Group, as far as I can tell. It doesn't follow patterns suggested by the draft vocabulary, Open Badges spec, or Identity Credentials spec. As @dlongley pointed out is true about the Identity Credentials spec, if an issuer puts claims inside a claim property that has the @id of the recipient, these claims can be pulled out with JSON-LD framing into an identity document that contains the claims a particular consumer trusts after that consumer has decided which credentials are acceptable.

The snippet you posted seems to say that the @id of the badge is https://foo.com/badges/1.1.41.c, and that @id node claims to be "about" one particular recipient, https://foo.com/i/erickorb. That doesn't mesh with the Open Badges vision and the DefinedAchievement class that says a defined achievement can apply to many recipients.

For example, the properties name, description, image, issueDate, and issuer should be properties of a DefinedAchievement class, but that class should not also have a claim property, because claim is a property of the Credential class. You can claim that an identity has received a particular DefinedAchievement by adding a DefinedAcheivementAssertion that makes the connection between that recipient and a badge to a Credential's claim.

As is true with the Identity Credentials spec examples, you don't need to use a DefinedAchievement to issue a Credential. Instead, you could assert properties directly about an identity with the claim property, such as in this case where a name and a birthdate is asserted about an identity (assuming an IRI mapping exists in the context for 'birthdate" -- added an example 'basicinfo' context that would presumably hold this type of mapping so that the credentials context itself can remain agnostic about the types of claims that may be made):

{
  "@context": ["https://w3id.org/credentials/v1", "https://example.org/contexts/basicInfo"],
  "credential": [{
    "id": "http://biguniversity.gov/credentials/53091",
    "type": ["BasicInfo", "Credential"],
    "claim": {
      "id": "https://example.com/identities/bob",
      "name": "Bob Bobman",
      "birthdate": "1985-12-14"
    },
    "expires": "2018-01-01",
    "signature": {
       "type": "GraphSignature2012",
       "creator": "https://biguniversity.edu/keys/1",
       "signature": "3780eyfh3q0fhhfiq3q9f8ahsidfhf29rhaish"
    }
  }]
}

But if you are using a DefinedAchievementAssertion to make a claim that someone has earned a badge, that goes inside the claim property of the Credential (excuse a few broken IRIs -- context still needs a bit of refinement):

{
   "@context": "https://w3id.org/credentials/v1",
    "id": "http://biguniversity.gov/credentials/53091",
    "type": ["UniversityDegree", "Credential"],
    "claim": {
        "id": "https://example.com/identities/bob",
        "badgeAssertion": [
            {
                "@context": "https://w3id.org/openbadges/v1.1",
                "id": "https://biguniversity.edu/credentials/53091/badge",
                "type": "Assertion",
                "recipient": {
                    "identity": "bbob@example.com",
                    "type": "email",
                    "hashed": false
                },
                "issuedOn": "2015-03-01",
                "badge": {
                    "id": "https://bigunivertsity.edu/credentials/BA",
                    "type": "BadgeClass",
                    "name": "Bachelor of Arts",
                    "description": "The gold standard of credentials in liberal arts education",
                    "image": "https://biguniversity.edu/credentials/BA/image",
                    "criteria": "https://biguniversity.edu/credentials/BA/criteria",
                    "issuer": {
                        "id": "https://biguniversity.edu/id",
                        "type": "IssuerOrg",
                        "name": "Big University",
                        "url": "http://biguniversity.edu",
                        "publicKey": "https://biguniversity.edu/keys/1"
                    }
                }
            }
        ]
    },
    "signature": {
       "type": "GraphSignature2012",
       "creator": "https://biguniversity.edu/keys/1",
       "signature": "3780eyfh3q0fhhfiq3q9f8ahsidfhf29rhaish"
    }
}

This example makes a claim that https://example.com/identities/bob has earned a v1.x Open Badge (note: badge is issued to an email address bbob@example.com that the issuer trusts belongs to him, though the recipient field could be equivalent to the claim @id). The badgeAssertion (needs property name finalization and inclusion in credentials vocabulary/context) points to the DefinedAchievementAssertion that has been received by the claim @id identity, and that badge assertion points to the DefinedAssertion (badge) that has been awarded.

[ottonomy]

These changes included as part of #34