- From: Sunny Lee <sunny@badgealliance.org>
- Date: Fri, 23 Jan 2015 07:50:56 -0800
- To: Eric Korb <eric.korb@accreditrust.com>
- Cc: Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAATp=XYsuUboFzjrhMzcw5oKAYpQKrrRw001VieF3TT1tAc=eg@mail.gmail.com>
Howdy folks,
Thanks for the feedback. The following is the BA response. I put it in
etherpad format so folks can feel free to weigh in and comment directly:
http://etherpad.badgealliance.org/obi-vocab-review-credcg
Thanks,
Sunny
On Tue, Jan 20, 2015 at 5:02 AM, Eric Korb <eric.korb@accreditrust.com>
wrote:
> +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 Friday, 23 January 2015 15:51:24 UTC