- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Tue, 20 Jan 2015 10:02:44 +0100
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAKaEYhJ6+C0cVVzkz2WP2bHBdAFpOAyrXMxe+8MX9ATXFyo5Pg@mail.gmail.com>
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 09:03:12 UTC