Re: Review of OBI Badges vocabulary

+1 to everything

Per comment for hosted:  Yes, we see the use of hosted badges for K-12, but
Accreditrust is not interested in this form.  However, if wanted to host
badges in JSON-LD format in a single file via URL, here an example:

{
  "@context": "https://w3id.org/openbadges/v1",
  "alignment": [],
  "claim": {
    "about": "https://www.FOO.com/i/FOO"
  },
  "criteria": [
    "https://FOO.com/badge/criteria.php?cid=13&badge=66&award=944"
  ],
  "description": "4th Grade Level Basic Writing Skills",
  "evidence": "",
  "id": "https://www.FOO.com/i/FOO/badges/1.1.41.c",
  "image": "https://FOO.com/badge/13/images/basicwritingskillsbadge.png",
  "issued": "2014-02-10T06:00:00Z",
  "issuer": "http://www.accreditrust.com",
  "name": "4th Grade - Basic Writing Skills",
  "owner": "https://dev.FOO.com/i/FOO",
  "sysOpenBadges": {
    "assertion": {
      "uid": "944",
      "recipient":
"sha256$ff1fb520fb37a2fd35d4a1cc4caf2cd7ef808101367603e54f7329096e0e7a40",
      "badge": {
        "name": "4th Grade - Basic Writing Skills",
        "description": "4th Grade Level Basic Writing Skills",
        "image": "
https://FOO.com/badge/13/images/basicwritingskillsbadge.png",
        "criteria": "
https://FOO.com/badge/criteria.php?cid=13&badge=66&award=944",
        "issuer": {
          "name": "Accreditrust, LLC",
          "url": "http://www.accreditrust.com",
          "email": "test@domain.com",
          "image": "https://FOO.com/badge/13/accreditrust_logo_70_rt.png",
          "description": "<p>Digital Achievement Curation and
Validation</p>",
          "_location": "
https://FOO.com/badge/13/Npperqvgehfg,_YYP-issuer.json",
          "origin": "http://www.accreditrust.com"
        },
        "tags": [
          "writing",
          "4th grade"
        ],
        "alignment": [
          {
            "name": "Align Name 1",
            "url": "http://www.example.com",
            "description": "Align Desc 1"
          },
          {
            "name": "Align Name 2",
            "url": "http://www.example.com",
            "description": "Align Desc 2"
          }
        ],
        "_location": "
https://FOO.com/badge/13/41/173-66-4gu_Tenqr_-_Onfvp_Jevgvat_Fxvyyf-badge.json
"
      },
      "verify": {
        "type": "hosted",
        "url": "https://FOO.com/badge/13/41/173-Revp_Tznvy-verify.json"
      },
      "issuedOn": 1392012000,
      "evidence": ""
      },
      "_originalRecipient": {
        "identity":
"sha256$ff1fb520fb3adadf2ads5d4a1cc4caf2cd7ef808101367603e54f7329096e0e7a40",
        "type": "email",
        "hashed": true,
        "salt": "4POq9rBZ"
      },
      "salt": "4POq9rBZ",
      "issued_on": 1392012000
    }
  },
  ],
  "tag": [],
  "type": "Badge"
}



On Tue, Jan 20, 2015 at 4:02 AM, Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> On 20 January 2015 at 06:27, Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
>> I took an action[1] last week to review the OpenBadges spec at:
>>
>> http://standard.openbadges.org/
>>
>> Here's the first rough review:
>>
>> > Open Badges Standard
>>
>> I don't think we should be calling this a standard yet. I know the BA
>> wants to call it a standard, but that word means something special at
>> the W3C, IETF, ISO, OASIS, etc. I think we'll get significant and
>> unnecessary push-back from W3C comms and legal about this if we proceed
>> w/ any language that positions this document as a standard. I know there
>> is a disclaimer in the doc, but I don't think that'll convince W3C that
>> people will understand the nuance that statement is drawing.
>>
>> > Portable digital credentials
>>
>> Badges, credentials, microcredentials - we need to get our terminology
>> straight between the groups.
>>
>> > embedding it into portable image files as digital badges
>>
>> The image file thing is a non-goal for Digital Bazaar, maybe we can
>> reword it to "optionally embedding"? The important bit is the data
>> format, not where you can stuff the data format, no?
>>
>> > JSON-LD context (v1.1)
>>
>> Lots of thoughts on the context, but don't have time to delve into all
>> of them right now. Maybe that'll be a separate review. In general it
>> looks like class names (words starting w/ caps) are intermixed with
>> property names (lowercased names). The definition of 'type' is slightly
>> confusing, unless the OBI type subclasses rdf:type. obi:validation seems
>> like it might need to use JSON-LD framing to work for non-trivial
>> examples.
>>
>> > They are published as JSON for interoperability.
>>
>> Why not as JSON-LD?
>>
>> > Badge Baking Hosted Verification Signed Verification
>>
>> This sort of content isn't usually found in a vocabulary document. It's
>> a part of a spec, like the Identity Credentials spec. I suggest moving
>> this stuff out to a separate document.
>>
>> > Hosted Verification
>>
>> I think we should be focusing solely on digital signatures for
>> verification. The whole hosted model is very problematic when you start
>> working with credentials that are mission critical.
>>
>> > Signed Verification
>>
>> -1 to JWS:
>>
>> http://manu.sporny.org/2013/sm-vs-jose/
>>
>> > Assertion
>>
>> > uid
>>
>> You don't need a UID if you follow Web Architecture principles. There is
>> just an identifier, which is a URL. That is both globally unique and the
>> identifier can be generated locally.
>>
>> The question is whether to map this to @id, or to have a new 'id' value
>> that is a URL and relegate uid to "legacy" status.
>>
>> > recipient
>>
>> +1 for this language over credentialee
>>
>> > badge
>>
>> The fact that both recipient, badge, and a few other properties are both
>> machine-readable and change is bad news for deep validation of badges.
>> This is going to cause a huge problem for digital signatures on badges.
>>
>> We're either going to need both 'badge' and 'badgeHash', or you're going
>> to need to deep nest the IdentityObject, BadgeClass, and
>> VerificationObject. If you don't do that, for example, the BadgeClass
>> could vary wildly over time w/o invalidating the digital signature
>> (which it should).
>>
>> > verify
>>
>> Again, I disagree with this approach to verification. The Hosted model
>> is not something that Digital Bazaar would be interested in supporting
>> in any other way than legacy support.
>>
>> > issuedOn - DateTime - Either an ISO 8601 date or a standard 10-digit
>> >  Unix  timestamp.
>>
>> no unix timestamps, they're incredibly difficult to read/debug and don't
>> really provide any benefit these days. Make the dates and times human
>> readable.
>>
>> > This must be a PNG or SVG image, and should be prepared via the
>> > Baking specification.
>>
>> -1 to Badge Baking being in the vocabulary document, or a core
>> specification.
>>
>> > IdentityObject
>>
>> > identity
>>
>> This should be an IRI or URL. Assigning badges to people's names is fine
>> for low-value badges, but again, Digital Bazaar doesn't really have an
>> interest in low-value badges.
>>
>> > type
>>
>> Could be confused with rdf:type and JSON-LD's @type. E-mail addresses
>> make bad long-term identifiers.
>>
>> > hashed
>>
>> -1 to hashed identifiers. Identifiers, especially in Linked Data, need
>> to be dereference-able.
>>
>> > VerificationObject
>>
>> Verification should be digital-signatures based. We could still support
>> this for legacy purposes.
>>
>> > BadgeClass
>>
>> +1 to the content of a BadgeClass, but why not move most of this up into
>> the top-level badge object? Doing so saves a great deal of headache wrt.
>> verifying the digital signature because you push developers to include
>> all of the important information in the badge itself (without requiring
>> an external dereference to figure out if the badge is valid).
>>
>> > IssuerOrganization
>>
>> > image
>>
>> markup looks malformed.
>>
>> > revocationList
>>
>> If we used URLs to identify badges, just dereferencing the badge URL
>> would enable you to see if it was revoked or not.
>>
>> > For example, if the issuer at example.org wants to add a foo
>> > property to the assertion, the property name should be example:foo,
>> > or preferably a dereferencable IRI describing the property, such as
>> > http://example.org/foo.
>>
>> "example:foo" would be dropped by a JSON-LD processor that doesn't have
>> "example:" mapped. The digital signature wouldn't cover the property. In
>> fact, things that don't map to the JSON-LD context are not going to be
>> signed and are thus not protected from tampering. This bit looks like it
>> needs more work as I think it creates a security hole in the spec.
>>
>> > Signed Badges
>>
>> Agree that signed badges are very important, disagree that JWS is the
>> best path forward.
>>
>> In general I think the following changes need to be made to the
>> specification:
>>
>> 1. The vocabulary should be extracted out into a separate document.
>> 2. Signing could just re-use the Linked Data Signatures specification.
>> 3. Everything else should go into an OBI spec (hosted, structure of
>>    badges, extensions, etc.)
>>
>> Unfortunately, there are a number of contradicting opinions above, so
>> we'll need some discussion to tease out where the group wants to go with
>> things like flat badges vs. nested information wrt. digital signatures.
>> Whether or not extensions need JSON-LD framing, or if we just require
>> extensions to do shallow nesting + JSON Schema checking against
>> compacted JSON-LD data for now. We may also want to talk about freezing
>> 1.1 and ensuring that the entirety can be expressed in an Identity
>> Credential and then move to the Identity Credentials format for OBI 2.0?
>> Just some food for thought, talk w/ everyone on the call tomorrow.
>>
>
> +1 to everything
>
> Though I can see why you would want hosted badges.  Some badges may not
> have the need for portability and just live on a (COOL) URI.  Hosting some
> static content is easy for most publishers.  They can always be made
> portable later with a signature.
>
>
>>
>> -- manu
>>
>> [1] http://opencreds.org/minutes/2015-01-13/#88
>>
>> --
>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>> Founder/CEO - Digital Bazaar, Inc.
>> blog: The Marathonic Dawn of Web Payments
>> http://manu.sporny.org/2014/dawn-of-web-payments/
>>
>>
>

Received on Tuesday, 20 January 2015 13:03:09 UTC