Dave Longley: "Usually, when trying to determine if two nodes in a graph are equivalent..." ✪
Dave Longley: Spec coming along, little bit of a time. See link. I updated a little text in hash section-- overview or introductory text: see link "#hash-paths" ✪
Dave Longley: This is a little more colloquial about how the algorithm works. If you have base understanding, you will see how "nodes are equivalent" ✪
Manu Sporny: Do we need some graphics to explain how this works? That's a pain and the graphics can come at the end. Normalization is hard enough to understand and it's great to have this colloquialism. A graphic or visual can help others undersrand. ✪
Nate Otto: Is detecting node equivalence for comparing two documents or to see if sub-properties, say from two different source nodes, should be nested within the same output nodes ✪
Dave Longley: If anyone would created an animated GIF, that would be great... process of bucket to paper. ✪
Dave Longley: Probably not. Difficult to do. The algorithm has an analogy--hook it up to the algorithm itself, not sure if it would work. ✪
Manu Sporny: Would it be possible to use (Javascript data visualization library) D3 to visualize how the data is actually sorted in the node.js library that has implemented this normalization spec. [scribe assist by Nate Otto] ✪
Nate Otto: (That's a paraphrase, not a question I'm asking of Manu) ✪
Dave Longley: You might end up writing a lot of code. Sounds complex, might be possible to do. Only purpose would be this exercise. ✪
Manu Sporny: Looking for ways to explain this--I think the language is fine. Just a thought. ✪
Manu Sporny: Other comments? New stuff this week is the hash-paths? ✪
Manu Sporny: Jump into badges and credentials vocabulary. Nate and Sunny took a review to BA, which provided feedback here (see link). ✪
Manu Sporny: I went back to it and provided more feedback. Nate or Sunny? ✪
Nate Otto: Is this format suitable for long-term archiving? ✪
Manu Sporny: Typically, work is captured in mailing lists bc W3C assures long-lived libraries and archives. Ideal case is that discussions happen in the mailing list. Date, time, URLs captured. Etherpads handy for meetings, then move to mailing list. ✪
Nate Otto: Good discussion was generated. Point of this review you want to discuss, Manu? ✪
Manu Sporny: Main realization is that it's going to be very difficult for us to create one document out of this discussion. Different goals by different groups--e.g., BA for backward compatibility. ✪
Manu Sporny: Credentials CG doesn't have the same implementation pressure (yet). We're in a position that we cannot ask the BA to change a lot of the vocab they have. ✪
Manu Sporny: The path forward: one vocab with a date for future; two vocabs; 2 diff JSON-LD contexts. If 2 versions, we don't have to discuss breaking vocab changes. ✪
Manu Sporny: For the future, we can discuss in a different conversation--separate vocabulary. "Old" and "New" JSON-LD contexts. Hard to carefully thread a need like ISO time stamps. Clients would have increased complexity. ✪
Nate Otto: I agree--I am trying to write software to account for any badge written any time. When we make a breaking change--make it rare and carefully considered. ✪
Nate Otto: Making a dedicated vocab for things that will be deprecated: we don't know exactly what will be deprecated. Make sure that OpenBadges model (powerful and expressive) can be used. ✪
Nate Otto: Organization A badge - powerful trust statements - who is trusted by whom. Breaking change needs to be only once? ✪
Nate Otto: Mary, sorry for the disjointed long ramble! Hard to transcribe I'm sure ✪
Nate Otto: @Vocab is a sledgehammer, we want a scalpel ✪
Manu Sporny: Since we're using JSON-LD, the OBI stuff could just go off in its own direction. You can just assign a vocab to a sub-tree and if it comes valid... Even in the worse case, no coordination between the 2 groups, you can still take... ✪
Nate Otto is scribing.
Manu Sporny: Going back... We were discussing how the OBI stuff could basically go off on its own and could still be integrated into the identity credentials spec, because it's going to still use JSON-LD going forward. The only base requirement is that it uses JSON ✪
Nate Otto: We're going to be looking at "how to package deep nesting of badge class / inside delivered representation inside credential". [scribe assist by Manu Sporny] ✪
Nate Otto: We will be fixing that quirk over time - breaking change of some sort. There will still be a good compatability path in the future. [scribe assist by Manu Sporny] ✪
Eric Korb: In the TrueCred platform, we have a export path implementation set up. Would be happy to work with you on that ✪
Eric Korb: In TrueCred, we can export OBI and import OBI - we have a vocabulary to do that. I can provide samples. [scribe assist by Manu Sporny] ✪
Nate Otto: Looking forward to having you in those conversations ✪
Sunny Lee: Where do we go from here after netting out feedback? ✪
Manu Sporny: My personal thoughts are that we want to focus on producing some documents. The easy focus is the vocabulary document, which doesn't require any breaking changes to anything ✪
Manu Sporny: The next step is the JSON-LD context, which shows how to use that vocabulary document in a JSON-LD implementation ✪
Manu Sporny: Next step is to decide what to do with the OBI. Whether to put OBI items known to be to-deprecate into a separate document ✪
Manu Sporny: 1. Definitely do a known-to-be-moving-forward vocab, 2. then maybe a to-be-deprecated vocabulary, 3. Then maybe a to-be-deprecated context ✪
Manu Sporny: Then splitting out some badge-specific steps like splitting out the to-be-deprecated to its own context ✪
Sunny Lee: How do we know how consensus has been reached ✪
Manu Sporny: We typically take a straw poll. Doesn't mean that absolutely everybody agrees, but that the majority move on a best path to move forward. ✪
Manu Sporny: There is an extensive w3c document on consensus. If someone disagrees about the path to move forward -- if someone has an objection, we do a vote, which is a long 2-3 weeks process. We try not to do a vote to resolve formal objections because it takes so long ✪
Manu Sporny: Typically we almost never vote. We typcally talk through problems and come to solutions that work for the whole group. Typically isn't a contentious process. ✪
Manu Sporny: Other thing to note is that we are not an official w3c group, but we are following the same process as the official groups ✪
Sunny Lee: My question: wondering how the BA standard work fits in and how can we prevent fragemention of the work, how do we ensure we don't create similar but ultimately different standards? ✪
Manu Sporny: Here's something that could cause fragmentation: if the BA decides it isn't interested in Identity Credentials... it could create two ways of issuing badges or credentials out there, a BA approach and an Identity Credentials approach. ✪
Manu Sporny: If there's no path for these technologies to converge, it could cause fragmentation ✪
Manu Sporny: Here's an example; if in the 2.0 Badge spec, if a decision is made to continue to use JOSE for digital signatures and focus on hosted assertions to validate, that doesn't mean that this approach couldn't be standardized. They could be cases that apply to different communities with different sets of goals. ✪
Manu Sporny: With standards, we really really really try to create unified standards that work as broadly as possible, but sometimes two communities can't figure out how to merge their initiatives and you end up with two standards that end up doing their own thing ✪
Eric Korb: Supporting the same LD vocabulary and structure goes a long way to keep the applications together. ✪
Manu Sporny: In order to prevent that from happening, we have to talk about what's the migration path for the vocabulary set that we have... how is existing badge info expressed in Identity Credentials in the future? .. Are breaking changes to Badges in the future going to go in a different and more breaking direction? ✪
Eric Korb: The JWT and HTTP Signature standard track will work itself out. ✪
Dave Longley: I would add that I don't think there's any danger that we would accidentally create similar but different standards ✪
Dave Longley: As long as we're all working on the same documents, these documents should ultimately be compatible ✪
Dave Longley: In the case where we are trying to create something similar, we will be able to come to consensus ✪
Manu Sporny: For that kind of fragmentation to occur, you have to essentially have someone walk away from the table ✪
Manu Sporny: The things that lead to that tend to be a huge disconnect in communication. ✪
Eric Korb: @Sunny Is the BA going to start their own W3C effort? ✪
Eric Korb: AFAIK no [scribe assist by Sunny Lee] ✪
Sunny Lee: Doesn't seem for us to have any reason to considering this cred cg work, no? ✪
Nate Otto: On the vocabulary - entities defined in that document - wrote out 4 classes following commerce vocabulary. Goals that we're trying to accomplish - badge class. You may have seen my email to credentials list from Sunday night - do we call an identity document that we call that a credential or a collection of credentials. [scribe assist by Manu Sporny] ✪
Manu Sporny: I agree with those statements, Nate ✪
Manu Sporny: I don't think you can have a bunch of different credentials and then also call the document that they're put into a (singular) "credential" ✪
Manu Sporny: The "identity document" terminology goes back a decade or so: so you have this document on the web, and that document is a kind of container, an expression of your identity or one facet of it ✪
Nate Otto: It's a more powerful metaphor to - a collection is fit for purpose. Containers to put multiple credentials into. [scribe assist by Manu Sporny] ✪
Eric Korb: @Manu It might be good to tell the community about our positioning on Identity ✪
Dave Longley: Want to add some comments to that. I think we're in agreement that ID document is a container of credentials ✪
Dave Longley: Also the point that a crednetial is "a particular set of claims made by a single issuer", though it could be endorsed by another ✪
Dave Longley: Dlongley, Nate's quote from a sociologist might be an important part of the definition of credential. The claim about the data making an identity suited for a particular job or opportunity. We might want to say that a credential is a claim about an entity that makes it well suited to take a particular action ✪
Dave Longley: Suppose you took a test, got an A. The results of the test is not necessarily the credential, btu the fact that you took the test and passed might be the content of the credential, whereas the fact that you took a test during that class and got an A might not be the credential itself ✪
Manu Sporny: Out of time for today, but this is a good discussion and the stuff that we're going to get into even more ✪
Manu Sporny: These are the types of discussions we have to have in order to produce a good vocabulary document and a good roadmap document ✪
Manu Sporny: I'm hearing more alignment than not. I'm not hearing widespread disagreement ✪
Manu Sporny: There has been an incredible amount of thought into how we're modeling these issues in the identity credentials spec ✪
Manu Sporny: In coming weeks, we'll have to drill into this so that we understand the nuances in these different data models ✪
Kerri Lemoie: Good luck next week, Manu. Looking fwd to hearing how it goes. ✪
Manu Sporny: This call canceled next week, (unless volunteer). I'm going to be in the Netherlands pushing the credentials agenda at the Web Payments IG meeting ✪