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

Credentials CG Telecon Minutes for 2014-11-18

From: <msporny@digitalbazaar.com>
Date: Tue, 18 Nov 2014 12:33:58 -0500
Message-Id: <1416332038817.0.24503@zoe>
To: Credentials CG <public-credentials@w3.org>
Thanks to Manu Sporny and Dave Longley for scribing this week! The minutes
for this week's Credentials CG telecon are now available:


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-18

  1. Groningen Declaration
  2. Digital Signatures for Credentials
  Manu Sporny
  Manu Sporny and Dave Longley
  Manu Sporny, Victoriano Giralt, Eric Korb, Brian Sletten, Mary 
  Bold, Dave Longley, David I. Lehn, Sunny Lee, Rob Trainer

Manu Sporny is scribing.
Manu Sporny:  Any updates/changes to agenda?
Manu Sporny:  We may want to add the "Work Streams" email to the 

Topic: Groningen Declaration

Background on the Groningen Declaration - 
Victoriano Giralt:  Here's the link for today  - 
Victoriano Giralt:  This is a bit basic, but summarizes the ideas 
  behind what we're trying to achieve.
Victoriano Giralt:  We're trying to fight the diploma mills - the 
  fake diploma producing entities - you can buy a fake university 
  diploma for very little money.
Victoriano Giralt:  We're also trying to ease access to diplomas 
  - following a great idea from Stanford, all documents are born 
  digital. We're trying to get rid of paper.
Victoriano Giralt:  If you have digital diploma deposits - reduce 
  fraud, recover from diploma loss, reduce friction.
Victoriano Giralt:  If it's in digital form, it's easy to 
Victoriano Giralt:  As I was brought into this activity from my 
  digital identity background - if we mix digital identity w/ 
  digital diplomas/credentials - you have clear control of privacy, 
  access control, compare the data, produce credentials from one 
  university to be accepted by another one.
Victoriano Giralt:  We're working on a way to ease the 
  recognition of univeristy diplomas. One of the biggest problems 
  w/ paper-based university diplomas - you have to find an 
  authority to vouch for those credentials. That's a lot of work.
Victoriano Giralt:  Most of the people that do credential 
  verification need to be trained by police and banks. There are a 
  couple of slides in the presentation - better to have information 
  in electronic form.
Victoriano Giralt:  Easy to transport, easy to store, easy to 
  transmit, better for the environment.
Eric Korb: We experienced the same issue of verifying paper 
  credentials on incoming students to the US.
Victoriano Giralt:  We want to base all work on standards and 
  trust. There is the usual ancronym soup that come up in all this 
  work. TCP/IP to MLO ELM ELMO.
Victoriano Giralt:  MLO - Mobile for Learning Opportunities.
Victoriano Giralt:  ELMO European Learner Mobility.
Victoriano Giralt:  You see OpenID, or JSON, or PDF signed/not 
  signed, etc.
Victoriano Giralt:  We're fortunate in Europe - activity called 
  STORK - transborder digital identity for European citizens. 
  Having a common way of expressing identity and connecting to 
  unviersity diplomas is something that'll help this work.
Victoriano Giralt:  We have EDUGain - get identities created by 
  many universities.
Victoriano Giralt:  Groningen Declaration is about pulling all 
  this stuff together.
Victoriano Giralt:  We're talking about trust - we want to build 
  trustworthy connections. We also want technical trust - we want 
Victoriano Giralt:  Three laws of crypto - very important for 
  credentials - confidentiality, integrity, non-repudiation.
Victoriano Giralt:  We want student to leave home institution to 
  receiving institution, all can be mediated from depository of 
  university diplomas.
Victoriano Giralt:  Over a trust fabric over behavioral and 
  technical connections. We're trying to bring players together - 
  code of conduct, best practices, etc.
Victoriano Giralt:  You are being bound to a certain set of 
  principles wrt. electronic diplomas - network of trustworthy 
  institutions, easy for students to move from institution to 
  institution using this trust fabric that's been built. This is 
  simply what we want to achieve. It's not simple, but hopefully 
  that helps give background.
Brian Sletten:  What's the triggering event where they start to 
  get some of these credentials?
Victoriano Giralt:  It can be at several points - you can move 
  from one university to another. 
Victoriano Giralt:  You can then go back to the starting 
  institution, or finish in a different one - at some point.
Brian Sletten:  Does that model of credentials swimming across 
  multiple providers - is that covered in the use cases?
Victoriano Giralt:  I'll help w/ adding use cases along these 
  lines. I'll try to send something in.
Manu Sporny:  This is absolutely inline with what we're doing 
  here. Certainly with the technical work we're doing, it's meant 
  to enable what you're talking about. I would argue that we 
  already have what you want in the use cases right now, but please 
  take a look through them and if you see it's not in the use cases 
  we'll add it. [scribe assist by Dave Longley]
Manu Sporny:  I think what you presented is inline with our work 
  here. [scribe assist by Dave Longley]
Eric Korb:  I see exactly what you're trying to do here, the 
  issues you're addressing was the birth of the idea of the 
  Credentials CG work. We want to prove beyond a shadow of a doubt 
  to say who issued a credential and who received a credential. 
  We're in lock-step with your thinking. We have a demonstrative 
  system if you'd like to see it.
Victoriano Giralt:  That's what we thought when we saw the Open 
  Badges work. These are the technical grounds that we need under 
  our policy ideas.
Victoriano Giralt:  It's great that we've found each other, we're 
  in lock-step. At Groningen Declaration - we're working at policy 
  level, not technical level. I've always said that the technology 
  underneath is something that was done - it's somewhere. It was on 
  the net.
Mary Bold:  Question - remind me if in our approach to use cases, 
  we've taken a variety of points of view. Have we used 
  point-of-view as a goal for the use cases. Express via 
  institutional desire.
Manu Sporny:  We've taken a very individualistic view, we haven't 
  really talked about institution use cases and that may be a gap 
  that needs to be filled. [scribe assist by Dave Longley]
Mary Bold:  I think the processes are reflected in our use cases 
  - but the point of view may not be.
Dave Longley:  I think in the last iteration, we tried to put in 
  prose examples of what the use case could cover. What we may want 
  to do is offer two different prose examples from two different 
  points of view.
Dave Longley:  We do have roles, it would probably be helpful to 
  ensure that multiple points of views can be covered by the use 
Manu Sporny:  I think that's a good point, we do have the prose 
  in there for that purpose, but we haven't done it from the POV of 
  educational institutions/gov'ts as the first person, etc. [scribe 
  assist by Dave Longley]
Manu Sporny:  And we should do that. [scribe assist by Dave 
Manu Sporny:  One last comment, Victoriano -- this technology is 
  out there in beta and we need to finalize it. We need to figure 
  out best practices and take it through the W3C process to 
  standardize. But what you just said, I didn't hear anything this 
  group, from a consensus basis, would disagree with. We all want 
  to see happen what you've outlined. [scribe assist by Dave 
Victoriano Giralt:  Yes, it's clear that you have what's needed. 
  Very happy to connect our efforts.
Victoriano Giralt:  Great that we can have a technology track in 
  our next years meeting. It'll be great to have some 
Victoriano Giralt:  We agree that the individualistic view should 
  be the main one. Institution to institution flows should happen, 
  but having individual in control of their own data is a very 
  important thing.

Topic: Digital Signatures for Credentials

Dave Longley:  This is mostly about us pinning down the common 
  areas about what BA is trying to do and what we're doing w/ 
  Credentials work.
Dave Longley:  Is BA interested in using JSON-LD stack vs. JOSE 
Dave Longley:  It seems like there wouldn't be too much push-back 
  to move from BA's perspective... so, let's get started w/ the 
Dave Longley is scribing.
Manu Sporny: Sunny_: Some discussion  between Nate and Chris 
  McAvoy - we are trying to align w/ JSON-LD. We do want to do due 
  diligence, we have a signed credential feature for Open Badges, 
  find out how many people are using it. Pick their brains about 
  how the process has been for them, get some input from them. 
  Generally favorable, but we're going to do more due diligence.
Manu Sporny: 
Manu Sporny:  We want to take our time here and discuss this. 
  It's important we don't get it wrong. It's the basis for trust in 
  the system so the basis for this discussion is to understand that 
  it's going to take a few weeks to get through this and go through 
  pros and cons, etc., to make sure we get it right.
Manu Sporny: Secure Messaging vs. Javascript Object Signing and 
  Encryption - http://manu.sporny.org/2013/sm-vs-jose/
Manu Sporny:  I tried to summarize where we are in the email. 
  There's a very in-depth blog post that was done in 2013 about 
  Secure Messaging vs. the JOSE stack and Digital Bazaar's concerns 
  with it. Keep in mind JOSE is deployed, bits are finalized other 
  bits are still being worked on. Large companies are using it for 
  org-to-org communication.
Manu Sporny:  The main problem we had was that it was a fairly 
  bad fit with JSON-LD. It's fairly difficult to work with from a 
  dev perspective; once you do a digital signature your data 
  becomes unreadable and opaque.
Manu Sporny:  That is one of the things that caused us to think 
  about it more deeply; in general, the JOSE stack is nice in that 
  it allows you to do encryption and digital signatures on data, 
  but the data that ends up being signed becomes unreadable blob of 
  information. When you're seeing credentials moving back and forth 
  you want to be able to see that data easily.
Manu Sporny:  We think the JSON-LD/Secure Messaging stack is 
  easier because it's got a clear text signature, meaning the data 
  is untouched and you can read it. The JOSE stack encapsulates 
  everything in a binary blob and you get the signature on that. 
  You need special tools to even look at the data.
Manu Sporny:  The other bit with JSON-LD is that there's an 
  extensibility mechanism that's built in from day one. JSON-LD was 
  designed so that you'd have a data format that was very 
  extensible. You don't have to coordinate with some organization 
  to extend the data. If you want to put "homepage" into your 
  badge, you don't have to go lobby an organization to put that 
  data in there, you just create a vocab that is designed for your 
  market vertical (eg: medical creates a medical vocab, life 
  sciences does the same, etc.). You can just extend the base 
  format on your own in a way that is standardized.
Manu Sporny:  Meaning that the mechanism to extend is a 
  standardized, it's one of the things JSON-LD is about.
Manu Sporny:  The JOSE stack doesn't necessarily have that. Now 
  you could put a JSON-LD object into JOSE and convert it to a 
  binary blob and sign that, but then developers can't look at it 
  -- and if you ever wanted to recreate the signature and check to 
  see if it checks out, you have to have the original blob.
Manu Sporny:  With JSON-LD it's based on a data model called RDF 
  that multiple different syntaxes can all map to.
Manu Sporny:  That data model has been in use for more than a 
  decade, it's basically the data model "for the Web". Scientists, 
  technologists, etc. got together and said this was the way to 
  model the data on the Web. That open data model is really 
  important for the extensibility of it.
Manu Sporny:  JOSE has taken an IETF approach. This says there is 
  one controller of the vocab and that's IETF. If you want to get 
  anything new into the protocol you have to go through the IETF. 
  The nice thing is that there's no barrier to doing this other 
  than having to know how to go through the whole process, but the 
  problem is that you have to standardize this stuff yourself to 
  use it.
Manu Sporny:  With JSON-LD you don't have to do that. If you want 
  to go through a smaller standards body you can do that, if you 
  are just 5-6 companies working together to create a common vocab, 
  that's fine. It all works.
Manu Sporny:  The JSON-LD perspective is more extensible, 
  supports more syntaxes, represents something W3C has worked on 
  for a decade, etc. All these things combined has helped make 
  JSON-LD do well.
Manu Sporny:  Hopefully that wasn't too much of a fire hose of 
  information. Does the data extensibility and the data model 
  aspect make sense to people?
Eric Korb:  I've already expressed it in writing in response to 
  your email, but I think this is the key in developing a system 
  for designing credentials that are best for their needs and 
  doesn't require consensus every time you want to describe a 
  credential. Every use case may have a different method for 
  describing information. For example if you had credential with 
  "givenName" vs. "familyName" that means the same thing but in 
  different countries that's how it's described and LD allows use 
  to do that with @context. Another example would be "institutions" 
  would be listed in a credential but what does that mean? Is that 
  the URL for the institution, a college within a university? Etc. 
  LD gives us the extensibility and semantics. So that's vital and 
  if we want to be able to implement that with digital signatures 
  we need the tech for that.
Brian Sletten:  I'm strongly in favor of the JSON-LD approach as 
  well, but playing devil's advocate, are there are essential 
  security issues in allowing anyone to describe whatever they want 
  does that mean it's easy to get things wrong? What are the 
  implications of letting people make arbitrary choices here?
Manu Sporny:  There are dangers at the protocol level and the 
  semantic level. At the protocol level the only real danger we've 
  found is that ... if people start publishing their JSON-LD 
  @contexts not via HTTPS but via HTTP, that's an attack vector. 
  But that's fairly easy to detect -- if a @context is loaded via 
  HTTP we reject it.
Manu Sporny:  MITM attack problem there. The best example we 
  found of this is in the financial industry. If you model a 
  transaction from one person to another and you say "source" means 
  the source account and "destination" means where the money is 
  going in the @context, then if that @context is served over HTTP 
  it could get intercepted and flip the meaning of "source" and 
Manu Sporny:  Does that make sense?
Brian Sletten:  Yes. I think having a larger example-driven write 
  up and these things we're talking about and how to protect 
  against them. If this exists please point me to them. I'd like to 
  work with you on this and expand the discussion so it isn't just 
  in your head, etc. It's useful.
Manu Sporny:  Definitely. It's something we want to put in the 
  spec. It would show up with "You shall not serve your @context 
  over HTTP" etc.
Manu Sporny:  We need to do that and we need a security 
  consideration section in the spec and that's where we'd elaborate 
  on that and we'd love to have your help on that.
Victoriano Giralt:  May I also suggest that we keep in mind -- 
  there are effective MITM for HTTPS, if the user trusts some 
  certification authority and some of the network appliances now do 
  that in the universities, ask for things like key pinning, etc. 
  Things like that, so if people fiddle with certificates along the 
  way -- we should consider those attack vectors.
Manu Sporny:  Yes, absolutely. Security is like an onion -- many 
  layers to get the right security you want. That should go in the 
  security section.
Manu Sporny:  You can do multiple levels of digital signatures -- 
  you can digitally sign JSON-LD @contexts, etc. We can secure via 
  HTTPS certificate, we can sign HTTP headers (HTTP Signatures) we 
  can include a header of the content and sign that, we can sign 
  the JSON-LD message itself. There are 3 layers there that need to 
  be compromised to fake a credential in transmission.
Manu Sporny:  That's more security than a lot of systems now; we 
  feel that we have a strong security solution.
Manu Sporny:  This are all very good comments and should go in 
  the security section in the spec.
Manu Sporny: http://manu.sporny.org/2013/sm-vs-jose/
Manu Sporny:  For those that don't deal with digital signatures 
  that much this will feel abstract/foreign, but if you go the blog 
  post via the link in IRC... the header is called "JSON Web 
  Signatures vs. Secure Messaging"
Manu Sporny:  There are two examples of what the signatures look 
  like. The top is the JOSE-based signature the bottom is JSON-LD.
Manu Sporny:  That's the difference between the two mechanisms. 
  If you look at "kid" in the top example that means "Key ID". This 
  is the other problem we have with JOSE is that they use a bunch 
  of 3 letter acronyms instead of spelling things out.
Manu Sporny:  Which makes it more difficult to figure out. 
  Anyway, the "kid" is known to the receiver and how keys are 
  registered/understood is out of band.
Manu Sporny:  With the JSON-LD signature you can see "creator" 
  which is the URL for the creator of the signature which is the 
  public key.
Manu Sporny:  The advantage with the JSON-LD signature is that we 
  use URLs for everything, you can go to that URL and get the 
  public key and check the owner of it, etc. You can see the data 
  that was signed and you can discover the key.
Manu Sporny:  Just with that, you can verify if the signature is 
Manu Sporny:  In the first system there's no explanation for how 
  to get the key (out of band) and in the second, there's a clear 
  way to get it.
Manu Sporny:  The Secure Messaging approach turns the entire Web 
  into a PKI -- and does it in a machine readable way. When you get 
  a message you don't have to figure out a way to get the key of 
  the person that sent the message to you.
Victoriano Giralt:  May I just say I really like the idea, I was 
  teaching PGP to the students a week ago. I really like the idea 
  of turning the whole Web into a PKI. We just need to make sure 
  it's secure, but once that's figured out it's a great idea.
Dave Longley:  Technically speaking, you can get away w/ an HTTP 
  URL in that case - you have to follow the key back to the owner. 
  [scribe assist by Manu Sporny]
Victoriano Giralt:  Having things be machine readable for 
  university document exchange and if you give that to a machine 
  the machine can also make sense of it. I really like this concept 
  that we're presenting here.
Manu Sporny:  Something else to mention is that we're not going 
  into this with no support. There are a number of other groups at 
  W3C that are using JSON-LD as their primary syntax. Like the 
  Linked Data Platform group, where you must support JSON-LD.
Manu Sporny:  Because of that requirement, there are knock-on 
  effects, like they have to be able to prove data came from 
  somewhere and the easiest way for them to do that is to reuse the 
  JSON-LD signature mechanism.
Manu Sporny:  So it works really nicely with the Linked Data 
  Platform because the digital signature mechanism doesn't just 
  work with JSON-LD it works with any linked data syntax.
Manu Sporny:  The Social Web WG has also just adopted JSON-LD as 
  their primary data format and they have to have a digital 
  signature/secure messaging mechanism and that's a requirement 
Manu Sporny:  The Web Annotations group (e-book readers, etc) ... 
  like if you want to go to a website and mark something up and 
  annotate it -- anyone can do that with the tech they are working 
  on. They need a digital signature mechanism.
Manu Sporny:  This is what happens at W3C TPAC -- each one of 
  these groups said they want to see this work happen.
Manu Sporny:  So it's not just this group acting on its own, it's 
  us acting with those groups and -- it's too early to tell now -- 
  but we're pushing for this work in the Web Payments group as 
Manu Sporny:  Hopefully that made sense.
Manu Sporny:  We're almost out of time; the thing that makes me 
  nervous about it is that we really need to have people from the 
  JOSE community make counterarguments. We need to find some real 
  strong supporters of JOSE and JWS; mostly people that have 
  implemented it to see why they picked it/if they have 
  counterarguments against Secure Messaging/JSON-LD stuff. So if 
  anyone knows anyone like that we can reach out to and pull into 
  this discussion that would be great.
Manu Sporny:  I know people that have used JWS and they really 
  didn't like it ... and they say they'd much rather use the 
  JSON-LD stuff, but we really need is someone who is really sold 
  on JWS and has done a big deployment of it, someone from Google, 
Manu Sporny:  I don't think we can say we've fully done our due 
  diligence without having that debate.
Victoriano Giralt:  I don't think it's a big deployment around 
  the mobile applications/identity frameworks, I know someone who 
  has implemented OpenID Connect the validator through IETF and 
  European org work and I can ask this guy if he's been happy.
Manu Sporny:  That would be great. We had one person chime in on 
  the mailing list but it wasn't a ringing endorsement -- but we 
  should follow up.
Manu Sporny:  Please try to get your guy involved in the work 
  here, it would be great to talk with him and get his thoughts.
Victoriano Giralt:  I'll try to get him involved.
Manu Sporny:  I think that's the call for today, are there any 
  other thoughts in general on the JSON-LD/JOSE stack?
Manu Sporny:  We'll have more discussion on the mailing list and 
  circle back around on any point that needs further discussion and 
  add to the call. Thanks everyone!
Received on Tuesday, 18 November 2014 17:34:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:21 UTC