- From: Eric Korb <eric.korb@accreditrust.com>
- Date: Tue, 20 Jan 2015 08:02:16 -0500
- To: Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAMX+RnDJ0Yg8dnSKhYyE7Up9c2h70dvCAB-dDhVSJk621Z3Ung@mail.gmail.com>
+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