- 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