- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Sat, 24 Jan 2015 10:14:05 +0100
- To: Sunny Lee <sunny@badgealliance.org>
- Cc: Eric Korb <eric.korb@accreditrust.com>, Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAKaEYhLdoq63_vGy8djdbghNHvgR=niAS2YOfzb3v2jrh7E1CQ@mail.gmail.com>
On 23 January 2015 at 16:50, Sunny Lee <sunny@badgealliance.org> wrote:
> 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
>
+1 good progress
I'm definitely more likely to reuse this work with JSON LD
>
> 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 Saturday, 24 January 2015 09:14:34 UTC