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? ✪

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 ✪

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. ✪

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 ✪

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. ✪

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 ✪

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! ✪