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 recover. ✪
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 badges/credentials. ✪
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 cases. ✪
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 Longley] ✪
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 Longley] ✪
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 showcasing/demos. ✪
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. ✪
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 stack. ✪
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 discussion. ✪
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: 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: 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 "destination" ✪
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: 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 valid. ✪
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 there. ✪
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 well. ✪
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, etc. ✪
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! ✪