W3C home > Mailing lists > Public > public-credentials@w3.org > November 2014

Credentials CG Telecon Minutes for 2014-11-25

From: <msporny@digitalbazaar.com>
Date: Tue, 25 Nov 2014 12:57:44 -0500
Message-Id: <1416938264396.0.20225@zoe>
To: Credentials CG <public-credentials@w3.org>
Thanks to Nate Otto and Manu Sporny and Nate Otto for scribing this week! The minutes
for this week's Credentials CG telecon are now available:

http://opencreds.org/minutes/2014-11-25/

Full text of the discussion follows for W3C archival purposes.
Audio from the meeting is available as well (link provided below).

----------------------------------------------------------------
Credentials Community Group Telecon Minutes for 2014-11-25

Agenda:
  http://lists.w3.org/Archives/Public/public-credentials/2014Nov/0052.html
Topics:
  1. Digital Signatures - Pushback from Social Web / Harry Halpin
  2. Introduction to Dale McCrory
  3. Digital Signature Strategy
Organizer:
  Manu Sporny
Scribe:
  Nate Otto and Manu Sporny and Nate Otto
Present:
  Nate Otto, Manu Sporny, Brian Sletten, Dave Longley, Dale 
  McCrory, Chris McAvoy, Eric Korb, Mark Leuba, David I. Lehn
Audio:
  http://opencreds.org/minutes/2014-11-25/audio.ogg

Nate Otto is scribing.
Manu Sporny:  Today on the agenda, we are continuing the digital 
  signatures discussion, and coordination on how we may contribute 
  documents to the w3c for consideration. Any other updates to 
  Agenda?
No other updates to the agenda

Topic: Digital Signatures - Pushback from Social Web / Harry Halpin

Manu Sporny:  Hopefully everybody has been able to see the email 
  thread that broke out about the digital signatures discussion.
Manu Sporny:  Someone who is in both the Credentials community 
  group and the Social Media working group cross-posted
Manu Sporny:  I'm not going to contribute at this moment to the 
  discussion, but we can go around and everyone can give their 
  opinion.
Manu Sporny:  Anybody want to start?
Brian Sletten:  I'll go first. I'm newer to the W3c. I guess I 
  have more questions than comments. Hopefully we can use those as 
  a jumping-out point.
Brian Sletten:  I'd like to know more about the history.
Brian Sletten:  Henry mentioned previous conversations.
Brian Sletten:  Maybe we could discuss this history, and what it 
  would mean if the Credentials CG said "we want linked 
  signatures", what that would mean for adoption, and the 
  likelihood of these ideas moving forward as they are.
Dave Longley:  I have a quick comment on the history, the 
  security review that Harry mentioned
Dave Longley:  The security review Harry mentioned was a very 
  high level overview
Dave Longley:  The main goals were to provide a linked data 
  format and a single way of encrypting and a single way of signing 
  messages going across
Dave Longley:  There was a perception that the SM was a complete 
  and full spec rather than an early stage spec, so there were 
  comments about the algorithm that they picked
Dave Longley:  We had picked a commonly used signing algorithm, 
  which was criticised
  ...the algorithm that these reviewers suggested was very new.
Dave Longley:  They picked up on a typo in Manu's post, "cyclic" 
  block chaining instead of "cypher" block chain, and people 
  criticized "beginner crypto errors"
Dave Longley:  The discussion should have been about how to 
  contain the data, not the algorithm that they chose
Dave Longley:  This is different from JOSE, which says here are 
  all the algorithms, they all go through this central point; to 
  consider more, you have to go to the IETF and get approval
Dave Longley:  Choosing an algoritm is sort of orthogonal to the 
  questions that we were asking
Dave Longley:  It seems like this was a way to snipe the spec 
  down and dismiss it (and say "come back when you're more 
  serious") is how I viewed it anyway
Dale McCrory:  From "CourseLoad", on the educational technology 
  side of things
Manu Sporny:  We have never submitted the SM spec to the IETF for 
  security review
Manu Sporny:  We wrote up the problems with JOSE and suggested 
  some points as far as the direction that they should go
Manu Sporny:  But SM has never been submitted for a security 
  review. That is false.
Chris McAvoy: Would like to comment as well
Eric Korb:  We see JSON-LD as a key technology for describing 
  credentials.
Manu Sporny is scribing.
Dave Longley:  I'd like to agree with Eric as well - JOSE sets 
  out to create a container format for a blob of information that's 
  signed. It makes the data opaque. You can't work w/ the data in 
  its signed form. That's a problem that has a number of knock-on 
  effects.
Dave Longley:  Here are some problems that arise from that - one 
  of them is that, since you don't store the signed data itself in 
  JSON, you can't transmit it in a native JSON format. You can 
  transmit it as base64 encoded data, but you can't turn it back 
  into JSON and transmit it that way. Native JSON 
  parsers/serializers will screw up the signature.
Dave Longley:  That also means you can't use certain document 
  stores like MongoDB on the signed data itself... you lose the 
  cryptographic properties, you have to save it as base64, native 
  parsers will destroy data.
Chris McAvoy: +1 To above
Nate Otto is scribing.
Dave Longley:  Your data doesn't function as JSON after it was 
  signed in JOSE (scribe assumes)
Dave Longley:  It's harder to get at the data in a JOSE signed 
  document vs in the SM data format
Dave Longley:  One of the reasons JOSE exists was to replace 
  ASN.1, but it reminds me of ASN.1
Dave Longley:  It gets way down into the technical weeds, but 
  there are a lot of rules to follow for how all the data 
  structures are treated. ASN.1 is also hard to extend, because 
  extensions each require a new domain-specific parser
Dave Longley:  For example, a PCKS (sp) spec requires tweaking of 
  the data structures from the ones that were signed for transport. 
  Don't spend a lot of time thinking about that, because you 
  shouldn't have to.
Dave Longley:  In the ASN.1 space, rules are difficult to 
  implement. The JOSE stack removes that by removing a 
  canonicalization alg, but that introduces other problems.
Dave Longley:  The way data is serialized is one-off effort, you 
  don't have to keep implementing the serialization
Dave Longley:  The specific syntax by how you transport the 
  message is irrelevant. That's why you want a canonicalization 
  algorithm.
Dave Longley:  The text format for serializing data to be signed 
  is N-Quads, is a very simple algorithm and format to understand.
Dave Longley:  It uses the RDF data model. You implement it, and 
  it's done.
Dave Longley:  It gets nowhere close to the rules of ASN.1, but 
  it doesn't eliminate the serilization alg like JOSE
Dave Longley:  You get to see the data in the format that you 
  want it in (Linked Data as first class citizen)
Dave Longley:  You don't need to pile linked data into these 
  base64 blobs which need to be double encoded.
Manu Sporny:  Any other thoughts?
Nate Otto:  I've been trying to look at Open Badges issued by 
  many issuers over time. One of the problems that has caused me 
  the most headaches in this process, when I'm expecting to read 
  JSON data - I come across a big blob. Hardly anyone uses digital 
  signatures, but a couple of different fields change from strings 
  into JSON objects at one point in the spec. [scribe assist by 
  Manu Sporny]
Nate Otto:  When I was expecting something to be an object, and I 
  get a string. When you expect Linked Data and come across a 
  base-64 encoded blob. [scribe assist by Manu Sporny]
Dave Longley:  Harry made the point that there are many b64 
  encoders.
Dave Longley:  You can add more things into your toolchain, or 
  you can do it this way, and it's easier
Chris McAvoy:  We ran into a lot of problem with badges 
  encountering signatures as wrappers
Chris McAvoy:  We made up our own solution of including the 
  signatures in the body to draft. But now, with JSON-LD, this is 
  solved.
Chris McAvoy:  We saw that as a huge bonus for the community, and 
  it would make them a lot easier to implement it. It's an 
  important discussion, the reason that we're here is that we want 
  to be able to sign badges in a way that is easier to make 
  portable
Dave Longley:  A couple other points
Brian Sletten:  It seemed pushback was being driven by other 
  issues: presented as a standard when it isn't -- presented by a 
  community group not a standards grou
Brian Sletten:  It seems this is the point of community group 
  process, to explore problems and standards
Eric Korb: Yes, very contradictory position W3C is taking.
Brian Sletten:  I'm curious if my understanding of the CG process 
  is skewed, or if it's really intended to address things at a 
  technical level that aren't being explored in the Working Groups
Dave Longley:  CGs were places for people with good technical 
  advice, to incubate ideas and move them into the official space.
Dave Longley:  Allows work to be fast tracked once it becomes 
  part of the official space, because a lot of background had 
  already had been done. That was the intent.
Dave Longley:  It seems the CGs are viewed as an outlet for 
  people who aren't in the official space
Dave Longley:  With the email thread, it's almost disparaging to 
  all the people in community groups who try to further the web
Dave Longley:  Every email that comes out that says "that's just 
  a community group; it doesn't really matter" is damaging to the 
  w3c
Manu Sporny:  It's mainly Ian Jacobs (sp) and ____ who created 
  Community Groups
Manu Sporny:  It came out of the XHTML2 effort, which the w3c 
  lost.
Manu Sporny:  A group led by Ian Hixson forked the standards 
  body, and created a spec that eventually became HTML5
Manu Sporny:  W3C had lost credibility on its ability to pick the 
  right standard
Manu Sporny:  Community groups are basically a way for w3c to 
  allow experimentation to happen without the years-long process of 
  getting the blessing of all of its members
Manu Sporny:  I'm sure dlongley and dlehn remember how nasty 
  people were to us in the beginning. It was presented as this crap 
  specification that will go nowhere
Manu Sporny:  In the end of the day the thing that won out was 
  the fundamentally beautiful ideas that were in the specification
Manu Sporny:  I think Harry's reponse as a w3c staffer reflects 
  the thinking that w3c was doing in the XHTML2 days, everybody 
  singing kumbayaa and declaring victory, and now you this small 
  group is trying to split the specification
Manu Sporny:  Instead of talking about the technical issues, what 
  we're seeing are a whole bunch of process issues being thrown in 
  front of us
Manu Sporny:  This is way out of line from my standpoint and my 
  experience from working with w3c. It's happening because the SM 
  spec is a threat to the JOSE spec.
Manu Sporny:  We could very well be wrong. Everybody who's worked 
  on the secure messaging spec knows we do have some very solid 
  criticisms of JOSE
Manu Sporny:  JOSE is so far down the standards path that they 
  can't very well change direction at this point.
Manu Sporny:  When you're in a group for so long, it starts to 
  become kind of an echo chamber. You stop hearing that you might 
  have made a mistake after a few years.
Manu Sporny:  CGs are meant to do what they're doing: explore new 
  technologies & ...
Manu Sporny:  We've been through this and we're seeing the same 
  attitude again with the Secure Messaging stuff
Manu Sporny:  Assume we're wrong and we find that SM is a pile of 
  crap.
Manu Sporny:  (Hypothetical), and we have to swap JOSE in. We 
  would still have the ability to sign documents, but we have the 
  downsides with JOSE that we mentioned.
Manu Sporny:  It wouldn't mean we can't have digitally signed 
  credentials
Manu Sporny:  The secure messaging spec is the only piece of our 
  stack that is getting any pushback
Manu Sporny:  I'll put a pin in that for right now. I want to get 
  Dale McCrory to introduce himself.

Topic: Introduction to Dale McCrory

Dale McCrory:  I gave an intro on an earlier call as well. I work 
  at CourseLoad as a director of product management. I replied to 
  the thread on the JSON jwt approach.
Dale McCrory:  I had built a significant JOSE implementation 
  before
Dale McCrory:  I'm an enterprise pragmatist by nature; how does 
  enterprise integration happen? I've seen WS-* with good features 
  and extensibility points not get implemented.
Dale McCrory:  I saw that spec not get implemented because it 
  didn't work on all the platforms.
Dale McCrory:  I'm here because I'm interested in higher 
  education and identity and how students can use credentials 
  across their lifetime

Topic: Digital Signature Strategy

Manu Sporny:  We have a number of potential paths forward
Manu Sporny:  One of them is to give up on the SM stuff and go 
  with JOSE. That would be the easiest way forward to a technical 
  standard. The downsides being the ones dlongley, cmcavory, and 
  NateOtto have raised.
Manu Sporny:  I'm sure Harry and the JOSE group would love it if 
  we went that path
Manu Sporny:  One path is to say, "if JOSE is the best 
  technological solution, show us how we can overcome these 
  barriers we've identified"
Manu Sporny:  We have some experience in the Badge Alliance of 
  this maybe happening, that JOSE wasn't picked up.
Manu Sporny:  There absolutely can be competing specfications 
  between w3c and IETF. Harry's right that this is problematic.
Manu Sporny:  There is inflexibility in the JOSE group -- they 
  didn't change anything in response to our review, but we really 
  weren't expecting them to.
Manu Sporny:  Sometimes the only way to get that change is a 
  competing tech stack
Manu Sporny:  It's also important to note that JOSE and SM don't 
  have to fight one another. For example the JOSE key format is a 
  great key format.
Manu Sporny:  There may be way that we could constrain JOSE 
  binary blobs to certain fields. There are hybrid approaches we 
  could pursue here
Manu Sporny:  "We'd like to proceed with the SM spec, but we have 
  a plan B that uses JOSE"
Manu Sporny:  We got down the path far enough to see that JOSE 
  didn't look like the right solution, but we could have a 
  contingency plan if SM is shot down. (This would require a lot of 
  work)
Dave Longley:  What's going to be the same regardless: We need 
  RDF normalization alg. We need this regarless of signature 
  technology.
Eric Korb:  What's the importance?
Dave Longley:  Linked Data is about meaning. these technologies 
  allow you to use any of the syntaxes to express the same meaning.
Dave Longley:  It will effectively produce the blob that you 
  don't need to interact with. JOSE produces that blob at the 
  transport layer
Manu Sporny:  Turtle, RDF-XML, JSON-LD, all use the same data 
  model
Manu Sporny:  Graph normalization produces the same output from 
  any of these formats that express the same meaning
Manu Sporny:  The JOSE approach would basically to take the input 
  syntax, shove it into the base64 format for signing.
Eric Korb:  I suggest that you emphasize this as the top reason 
  for this effort
Dave Longley:  Harry did acknowledge that this is of interest and 
  potentially that it should be standardized
Dave Longley:  But that's just a piece of the whole signature 
  puzzle. That makes it possible to get a single serialized 
  representation of linked data. Regardless of the signing 
  technology, this is the input that will be signed.
Dave Longley:  That's where the paths diverge. We could transmit 
  the data as linked data, or we could use a JOSE container
Manu Sporny:  What we'll be signing is N-Quads. This is a very 
  foreign format for web developers
Dave Longley:  They'll have to do two steps, base64decode and 
  then convert to JSON-LD
Eric Korb:  This is essentially what we're doing now in our APIs 
  (at Accreditrust)
Dave Longley:  That's right
Dave Longley:  That's how the SM spec works. You're defining a 
  property that corresponds to the signature, and you're putting 
  that into its native format
Manu Sporny:  At this point, I wonder if we're close to a 
  consensus or figuring out a path forward
Manu Sporny:  One of the things Dale said is very important; we 
  need to be pragmatic about this
Manu Sporny:  We don't want to be in a fight with IETF with w3c 
  blocking
Manu Sporny:  We can get around this if there are enough groups 
  who want to try out the SM spec
Brian Sletten:  I think we're not doing the spirit of the 
  community group justice if we just roll over and say "I'll use 
  JOSE" - That said, having a contingency plan is also important
Brian Sletten:  We want to keep exploring and vetting the SM 
  ideas further, but we have to have a contingency plan too. I 
  wouldn't want everything else going on in this group to be 
  blocked by this point.
Eric Korb:  I agree with Brian's first comment, but maybe not the 
  second stance.
Eric Korb:  Our fallback is JOSE, they'll see that crack in the 
  armor and say, "why don't you just fall back now". We don't want 
  to give them that option.
Dave Longley:  We could [missed]
Eric Korb:  I think what dlongley just said was a better fallback 
  position than "let's just use JOSE"
Brian Sletten:  If it's that simple, why are we even talking 
  about SM then?
Brian Sletten:  I'm fine with that as a backup plan, I'm just 
  saying I think we need a backup plan
Dave Longley:  I think that highlights that there shouldn't be as 
  much push back on the messaging spec as there is
Dave Longley:  We should emphasize that this is a mechanism for 
  LINKED data
Dave Longley:  Maybe it would be less of a threat if they saw it 
  that way
Brian Sletten:  The name is a point of contention as well
Dave Longley:  Let's come up with a better name and avoid that 
  point entirely
Eric Korb:  If we switching things around, ... can our mechanism 
  work with OpenID?
Dave Longley:  It can be made to work like that, but... you can 
  always create a context for JSON data where you could make it 
  linked Data
Dave Longley:  We're trying to be able to compare meaning between 
  two different syntaxes
Manu Sporny:  With the secure messaging stuff, you're digitally 
  signing the meaning; with the JOSE stuff, you're signing a blob
Dave Longley:  You're always signing a blob
Dave Longley:  The difference is that with SM you don't have to 
  see the blob
Dave Longley:  With JOSE you have to take the exact same blob to 
  give to someone else so they can check it. With SM, the data can 
  be transformed into a variety of syntaxes and passed around the 
  web, but as long as you pass it through the algorithm that 
  signature can always be checked.
Eric Korb:  If JOSE didn't exist, would Social Web group be 
  required to use linked data?
Manu Sporny:  That group is close to using JSON-LD as a must 
  requirement, but for some reasons some of their members resist 
  that, so it's not a requirement
Manu Sporny:  It's in their charter to explore linked data
Manu Sporny:  If JOSE didn't exist, and (we had a standard 
  already), and they needed to sign something, they would probably 
  be able to pick up our standard on Social Web
Manu Sporny:  Harry's saying that JOSE has first mover advantage 
  and an international standard, but it's still a draft.
Manu Sporny:  It probably will be a standard in a few years, but 
  SM may be as well
Eric Korb: What does it take to become a WG?
Dave Longley:  To clarify, there is a standards level working 
  group at the IETF working on JOSE, we are just a community group
Manu Sporny:  We'll take some of this to a mailing list
Manu Sporny:  Soon we'll want to start directly engaging the JOSE 
  group, see if they're interested in responding to some of these 
  ideas
Manu Sporny:  If 20 member companies vote in favor of a group 
  becoming a standard, it can become an official working group. We 
  have 10 interested.
Manu Sporny:  It also helps to have a finished spec. We have a 
  spec that is roughly 80% done
Manu Sporny:  We'll talk again next week. Happy Thanksgiving to 
  those in the US or look forward to not talking with your American 
  colleagues later this week for everyone else!
Received on Tuesday, 25 November 2014 17:58:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:46:54 UTC