W3C home > Mailing lists > Public > public-credentials@w3.org > October 2019

[MINUTES] W3C Credentials CG Call - 2019-10-22 12pm ET

From: <kimdhamilton@gmail.com>
Date: Tue, 22 Oct 2019 15:39:24 -0700
Message-Id: <1571783964923.0.67228@okimsRazor.local>
To: Credentials CG <public-credentials@w3.org>
Thanks to Nate Otto and Kim Hamilton Duffy for scribing this week! The minutes
for this week's Credentials CG telecon are now available:

https://w3c-ccg.github.io/meetings/2019-10-22/

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

----------------------------------------------------------------
Credentials CG Telecon Minutes for 2019-10-22

Agenda:
  https://lists.w3.org/Archives/Public/public-credentials/2019Oct/0027.html
Topics:
  1. Agenda review
  2. Announcements and Reminders
  3. Action Items
  4. Credential Schema Specification
Resolutions:
  1. The W3C Credentials CG supports the rechartering of a 
    Verifiable Credentials Maintenance Working Group.
Organizer:
  Kim Hamilton Duffy and Christopher Allen and Joe Andrieu
Scribe:
  Nate Otto and Kim Hamilton Duffy
Present:
  Nate Otto, Gabe Cohen, Dan Burnett, Manu Sporny, Amy Guy, Jeff 
  Orgel, Kim Hamilton Duffy, Dmitri Zagidulin, Dave Longley, Shivam 
  Sethi, Orie Steele, Yancy Ribbens, Ganesh Annan, Heather Vescent, 
  Markus Sabadello, Christopher Allen, Ted Thibodeau, Kayode Ezike, 
  Kaliya Young
Audio:
  https://w3c-ccg.github.io/meetings/2019-10-22/audio.ogg

Nate Otto: I can scribe today
Nate Otto: @Manu do you have a quick link to the scribe 
  instructions to refresh my memory
Nate Otto is scribing.
Right on, just as easy as always.
Kim Hamilton Duffy:  We are just at time now. I'll go ahead and 
  get started with boilerplate.
Nate Otto is scribing.

Topic: Agenda review

Kim Hamilton Duffy:  Scribe selection. Change scribe 
  appointments. We have one today, Nate Otto (ottonomy). Then we'll 
  move onto introductions, reintroductions, reminders, progress on 
  action items
  ... Main topic today will be Gabe Cohen from Workday will be 
  presenting their credential schema draft. A few colleagues from 
  workday joining as well.
Kim Hamilton Duffy:  Any comments or proposed changes to agenda?
Kim Hamilton Duffy: https://www.w3.org/community/credentials/join
Kim Hamilton Duffy: https://www.w3.org/accounts/request
Kim Hamilton Duffy: 
  https://www.w3.org/community/about/agreements/cla/
Kim Hamilton Duffy: https://w3c-ccg.github.io/meetings/
Kimhd introductions and reintroductions. Anyone new or returning 
  member on the call? Add yourself to queue or speak up
I'm new
Kim Hamilton Duffy:  Chris, from MITRE, could you introduce?
Chris__MITRE_: I am Chris Buchanan. I am MITRE's area lead for 
  digital identity. Working the self sovereign identity space for 
  MITRE
Kim Hamilton Duffy:  Chrisboscolo can you introduce?
Chrisboscolo: I founded LifeID. It's been a while since I've been 
  to this meeting, but I have been a regular attendee up until a 
  couple months ago.
Kim Hamilton Duffy: https://w3c-ccg.github.io/announcements/

Topic: Announcements and Reminders

Kim Hamilton Duffy:  Announcements and reminders are kind of 
  light for a moment. As you know, we've decided to do our call for 
  scribes in advance. There is an incentive mechanism you can find 
  out about if you volunteer to scribe. Hopefully this will save 
  some time.
Kim Hamilton Duffy: https://zoom.us/j/7077077007
  ... we're still having the dedicated DID calls on Thursdays, 
  focus on DID Resolution. The zoom room is there.
  ... Those are Thursdays 8pm UTC (1pm PDT)
Kim Hamilton Duffy:  A few words about those calls. DID 
  Resolution is not in scope of the working group meetings. These 
  breakout meetings are intended to discuss things not in scope for 
  the official workgroup meetings.
Kim Hamilton Duffy:  If anyone has anything to add about that, 
  please speak up.
Dan Burnett: Great summary, Kim
Dmitri Zagidulin:  What is the relationship to the DID working 
  group?
Kim Hamilton Duffy:  You reminded me that if you're calling into 
  DID working group, remember schedule is interesting. 4th Tuesday 
  of every month that there is an alternate timezone friendly time. 
  Dan, can you speak to that?
Dan Burnett:  Actually it's the 4th and 5th tuesday where it is 
  timezone shifted. 4th week of month is convenient for US/Asia 
  pacific. 5th Tuesday when occurs is convenient for Europe/Asia 
  pacific. There is a call this week in 6 hours. There is a call 
  next week at a time convenient for Europe and Asia Pacific but 
  not North America
Kim Hamilton Duffy:  Thank you for clarifying.
Kim Hamilton Duffy:  Last announcement. The Chairs are going 
  through and closing out action items and work items. Anything 
  that has lingered for a while, we're going through to make sure 
  things are getting the attention they need. If they find tasks or 
  people, we'll do a matchup and get things moving along.

Topic: Action Items

Kim Hamilton Duffy: 
  https://github.com/w3c-ccg/community/issues?q=is%3Aopen+is%3Aissue+label%3A%22action%3A+review+next%22
Kim Hamilton Duffy: 
  https://github.com/w3c-ccg/community/issues/90
Kim Hamilton Duffy:  I'm not sure we have anything interesting to 
  review this time. The one we have right here is actually not 
  correct. I forgot to close one out. So, a good one to bring up: I 
  wanted to call out this thing we discussed last week, which is 
  the tracking of the Verifiable Credentials Maintenance Charter. 
  We called this out last week. manu had sent out a proposed 
  charter. We discussed it as a group. The Verifiable Credentials 
  Working Group is done, but how
Do we keep the VC Data Model up to date; the idea is we do that 
  in the context of the CCG. Do we need to do anything at this 
  point?
Manu Sporny:  Just getting consensus that the community is OK 
  with the charter that is being proposed would be good.
Manu Sporny:  We could do it two ways. During the call, we could 
  say "hey is everyone ok with the charter". If it looks good, send 
  to mailing list for further discussion with 7 day time block on 
  it, as feedback to the W3C management. I have not received any 
  objections to the maintenance charter at this point. It didn't 
  sound like there was anybody proposed. The CCG is the body that 
  kind of figures out what has consensus. So I think we're done. To 
  be truly done
With it, I think we should get some feedback from the group on 
  this call or the next call.
Kim Hamilton Duffy:  I'm thinking I like the idea of sending out 
  the "Any Objections" call over email. I can send that out, so if 
  we want to flip that around formally, we'll kick that process off 
  now by sending this email to the mailing list. If you have 
  questions, concerns take them to replies on the mailing list.
Kim Hamilton Duffy:  Do we need official owners of the group?
Manu Sporny:  What do you mean by owners?
Kim Hamilton Duffy:  In general for work items we have an 
  assignee. What do we call that?
Manu Sporny:  I'm imagining by default this will be the chairs of 
  the working group. Dan, myself, anyone else who wants to be in 
  the critical path.
Kim Hamilton Duffy:  Assigned to myself to send out call for 
  objections. manu, you have the charter, so I can link to that.
Manu Sporny:  Do you want to kick that off on the call with a 
  proposal to show support for the maintenance charter?
Manu Sporny:  I will find the link and we can do that later in 
  the call
Kim Hamilton Duffy:  Let me check the agenda; that was the only 
  issue before we move on, so if you want to send that ASAP we'll 
  make sure to do that in a break before the end of the call
Kim Hamilton Duffy: 
  https://lists.w3.org/Archives/Public/public-credentials/2019Oct/att-0008/workday-credential-schemas.pdf
Kim Hamilton Duffy:  Now we're ready to move onto the main part 
  of the agenda. Let me queue it up. Gabe from Workday sent a 
  credential schema draft. I wanted to invite him to the group 
  because there is some interesting discussion in there.
Kim Hamilton Duffy:  Let's go back to maintenance charter for a 
  second.
Manu Sporny:  For those of you who weren't on the previous call 
  where we discussed this, there is a proposal to renew the VC 
  working group as the VC maintenance Working Group. The purpose is 
  to maintain the specificaiton; make sure all IP processes are up 
  to date, make sure bugfixes are released in a timely manner, and 
  make sure work on the spec proceeds over the next 2yrs
Manu Sporny: VCWG Maintenance proposed charter: 
  http://htmlpreview.github.io/?https://github.com/msporny/charter-drafts/blob/msporny-vcwg-charter/verifiable-credentials-2019.html
Christopher Allen: +1
Manu Sporny:  We did review this before; it has been circulated 
  on the mailing list. We are just checking to see that nobody 
  would object to the creation of that group. Particularly 
  important because this group is responsible for checking 
  consensus and getting support in this area
Ted Thibodeau: Manu -- link to the source?  (immediately noticed 
  a typo in the mission -- `is maintain`  should be `is to 
  maintain`)
Ted Thibodeau: Manu -- never mind, I see the link in the doc
Dan Burnett:  Just a reminder this is a maintenance working 
  group; it is not intended for any substantial new work on the 
  spec. Only bugfixes and whatnot. We are not permitted to expand 
  the scope beyond the scope of the original working group. This in 
  no way prevents us from rechartering the group to do substantive 
  work in the future.
Dan Burnett:  Just wanted to make sure people knew this is 
  intended for maintenance work
Manu Sporny:  Proposed vote text coming
Ted Thibodeau:  Just a quick comment. Manu you said explicitly 
  and carefully maintenance, but everything in this doc leaves out 
  "maintenance"
Manu Sporny:  That is wording I deferred to Philippe. The very 
  end of the doc says "This group is in maintenance mode". That 
  might have special meaning to W3C Management, so I wanted to keep 
  it intact. I think Philippe wanted to keep the option open that 
  the group could be rechartered to do more than maintenance 
  without trouble; i.e. without changing the name. I think it's 
  clear in the mission that it is to maintain.
Manu Sporny:  Up to you TallTed if you want to suggest another 
  clarifying intention sentence.
Ted Thibodeau:  I'm concerned with two different groups with the 
  same name two years apart with different purposes
Ted Thibodeau:  The way we explained this is working groups 
  typically just continue, but the understanding is that they are 
  in maintenance mode only. But Philippe said that they preferred 
  over time to have it be a bit clearer that it is in maintenance 
  mode to adjust wording in the charter to say that. As manu 
  described, he didn't want to go as far as changing the name of 
  the group. If the name of the group was still Verifiable Claims 
  working Group there would be no
Change to the name. We're trying to follow what Philippe 
  considers best practice today.
It says verifiable claims
Kim Hamilton Duffy:  I think that is something we could just fix 
  as an issue

PROPOSAL:  The W3C Credentials CG supports the rechartering of a 
  Verifiable Credentials Maintenance Working Group.

Ted Thibodeau:  I'm looking at w3c fork; not the same as manu's 
  for. The HTML preview is the only option that will give you what 
  current proposal is.
Dan Burnett: +1
Manu Sporny: +1
Dave Longley: +1
Kim Hamilton Duffy: +1
Kim Hamilton Duffy:  There may be some issues that TallTed just 
  mentioned, but if you are ok with proposal type +1. You can type 
  -1 if you are against it, and please write in your objection
Amy Guy: +1
Ted Thibodeau: In spirit, +1...  but need clear path to submit 
  PRs for the preview linked aove.
+`1
Gabe Cohen: +1
Kayode Ezike: +1
Shivam Sethi: +1
Orie Steele: +1
Dmitri Zagidulin: +1
Kim Hamilton Duffy:  I will followup afterward with a call to the 
  mailing list and will note TallTed's proposed modification there.

RESOLUTION: The W3C Credentials CG supports the rechartering of a 
  Verifiable Credentials Maintenance Working Group.

Kim Hamilton Duffy:  I think we will be ready to make the final 
  call at next week's CCG.
Kim Hamilton Duffy: 
  https://lists.w3.org/Archives/Public/public-credentials/2019Oct/att-0008/workday-credential-schemas.pdf

Topic: Credential Schema Specification

Kim Hamilton Duffy:  We have Gabe Cohen from Workday. He's going 
  to present their draft schema. Here is the link to the proposal 
  that he sent out to the list. Just to queue up how that will 
  happen, I will ask Gabe to walk us through the document. Now is 
  your good chance to get an overview if you haven't read it.
Kim Hamilton Duffy:  Specifically we wanted to know if there are 
  areas they wanted feedback from this community; for community, we 
  wanted to discuss and have a QA session.
Gabe Cohen:  I'm here with a few of my coworkers at Workday. I 
  presented at IIW a few weeks ago. These schemas are stored on our 
  ledger, used on our platform, used for validating and giving the 
  data shape to all our credentials.
Gabe Cohen:  I noticed a reference in the VC Data model the 
  possibility of using a JSON schema for schema, but no examples.
Gabe Cohen:  We are in production and we have a need to issue 
  credentials against schemas
Is there accompanied any video to this presentation? Which I dont 
  see now
Gabe Cohen:  We have a few pieces of data, and then the schema 
  itself. The "pieces of data" are LD-like but not JSON-LD, just 
  using JSON-schema
Gabe Cohen:  The model shows the fields in this version of the 
  schema. The model 1.0 happens to reference a JSON-schema, but in 
  future could reference an LD schema or both.
Gabe Cohen:  The next thing is the DID of the author. A next step 
  is to reference a shared DID, but for now single. In future, 
  there could be a github-like Pull Request model for 
  collaboration.
Gabe Cohen:  Next is a version of the schema. The version changes 
  when a new schema is released, but everything else stays the same 
  (identifier may change?)
Gabe Cohen:  Next is authorship and timestamp of when the schema 
  is authored. Next the schema itself, which is a draft-7 
  JSON-schema. We like the use of JSON-schema because we don't have 
  to resolve additional documents about what a credential should 
  look like. It also helps on issuance when we need to know what 
  fields to fill out.
Gabe Cohen:  As a recommendation, we said that 
  additionalProperties which is required by JSON-schema should be 
  set to false always to promote consistencies between different 
  issuing parties
Gabe Cohen:  The main theory driving use of JSON-schema is to 
  allow things to be pretty flexible on the platform.
Gabe Cohen:  We could call out later on extensibility. We could 
  potentially "tag" schemas for searchability in platforms; you 
  could extend the model to do that. One thing I didn't mention is 
  signing. Before we write the schema ... so there's no confusion 
  about it being a linked data signature. I guess that's pretty 
  much it. Colleagues, anything to add?
Dave Longley: +1 To Kim, JSON schema is for validation, JSON-LD 
  is for semantics, they serve different purposes
Dmitri Zagidulin: +1 To Kim's point
Manu Sporny: +1 To what Kim's saying... :)
Kim Hamilton Duffy:  Clarification question, basic: One of the 
  things that was surprising to me was seeing that this seemed to 
  be a contrast between JSON-LD and JSON-schema. They serve 
  different purposes; are for different things. JSON-schema is 
  about required properties, where JSON-LD roots the document 
  semantically. I'm curious to get some more backstory. Am I 
  missing out on something that contrasts them?
Kim Hamilton Duffy:  I thought of JSON-schema as an additional 
  optional later; curious about your thoughts on JSON-LD
Gabe Cohen:  We kind of wanted to "just" use JSON-schema, and go 
  about agreeing on what a name is in a different manner by having 
  the concept of "authoritative schemas" on our platform, and 
  having the community agree there. It's lighter weight to have 
  schemas the community agrees upon.
Gabec coworker: nobody in our group had any familiarity with 
  JSON-LD. We had familiarity and tooling support for JSON, so we 
  leaned toward JSON-schema as a mechanism to define shape. As you 
  use the same "shape" over time, you naturally get to a consistent 
  vocabulary
Gabec coworker: we wanted to have immutability of schemas. 
  There's nothing that prohibits us from using LD in the future or 
  providing a secondary layer of semantic meaning on top of 
  schemas; it could be argued that consistent use of attribute keys 
  in a schema can substitute and can build semantic consistency.
Dmitri Zagidulin: 
  https://github.com/snowplow/iglu/wiki/Self-describing-JSON-Schemas
Orie Steele:  Thanks for presentation; I attended IIW. We at 
  Transmute also use JSON-LD and JSON-schema together. Exciting, 
  particularly, self-documenting JSON-schema. Similar to 
  "snowplow". That's another technology to look at for those 
  interested. My main question is ... inaudible.... credential 
  format.
Orie Steele:  The object members secured by the schema members in 
  many ways have terms overlapping with LD Signatures system. Which 
  means that you are using a JSON LInked Data Signatures? If you 
  are not, you should be much more clear about not doing that. 
  Personally I would love to see support for LD SIgnatures + 
  JSON-schema in one format. My proposal would be to add explicit 
  support for JSON-ld to the spec itslef.
Dave Longley: Note that JSON-LD 1.1 supports JSON literals -- can 
  mark `schema` with that and it will sign with a JSON-LD signature
Orie Steele:  ... Inaudible... If that doesn't work, one of the 
  things that is super confusing about LD, is people do 
  half-implementations of it, and then it weakens the spec by 
  muddying the waters. I'd want to use the spec with the implied 
  assumption that it would use JSON-LD.
Gabe Cohen:  That's valuable feedback. We're happy to support 
  Linked Data Signatures. We would appreciate some suggestions on 
  how we could define another signature format that is clearly not 
  linked data to avoid signatures
Manu Sporny:  I want to focus on some of the good things we agree 
  on. Clearly the community needs a specification for how to 
  specify credential schemas; hopefully doing it in a way that the 
  entire community gets behind. This is a super solid start at 
  doing that. The way the data is laid out, the fact that you're 
  using LD Signatures; the fact that you are doing cryptographic 
  hashing of schema/storing it ledger. These are all good 
  capabilities we've talked about.
Manu Sporny:  If the group feels this is a solid place to start, 
  is this a CCG work item, a DIF work item? How do we get together 
  to collaborate on this?
Kim Hamilton Duffy:  Gabec any comment on that?
Gabe Cohen:  Looking for you all for guidance on how we can best 
  contribute/collaborate
Markus Sabadello:  Yeah, so I agree with others this is very 
  interesting; I had a question about the identifiers
Orie Steele: Relatated Aries RFC, for using did urls to id 
  schemas: https://github.com/hyperledger/aries-rfcs/issues/129
Markus Sabadello:  ... Identifiers for locating schema on the 
  ledgers. You're taking DID of the author of the schema, then 
  creating a DID URL to identify the schema to locate. The way you 
  do this is interesting... there may be other ways to do it,maybe 
  by using path or query components of did URL as opposed to matrix 
  ...inaudible.
Markus Sabadello:  Use of "method specific parameter" is not 
  perfectly correct, just small detail; but fascinating that you're 
  doing it with DID URLs
Gabe Cohen:  One of our architects pointed it out to me last 
  night. I think this is a generic parameter
Manu Sporny:  You were saying you are looking for guidance on how 
  to do the work. This seems to have community work item all over 
  it. You're getting feedback that this looks awesome; it would be 
  great if we could pull it in and incubate it. For example, VC 
  working group could spin up out of maintenance mode to do 
  something and moved through standardization process pretty 
  quickly. Rough outline of this document is pretty good.
Dave Longley: +1 It seems like a few minor tweaks could bring 
  this inline with other techs/specs, the community could help with 
  that.
Manu Sporny:  The stuff we need to hone in on is the details. 
  Matrix parameter format maybe, use of LD maybe... some general 
  terms that are used, like name of author. I don't see a lot of 
  controversial stuff here, so we could probably move it through 
  community fairly quickly. That's just a suggestion; I'm seeing a 
  fairly clear path through. +1 to this being a CCG work item to 
  put this on a (maybe)fast track to standards process.
Manu Sporny:  Other comments are about what Orie and kimhd said 
  about proof formats, conflict resolution. There's a knowledge gap 
  there that community could help fill. JSON-schema and JSON-LD 
  were always designed to be complementary. It should be easy to 
  mix in JSON-schema and JSON-LD and put them together. In our work 
  in last 12 years we have combined these in customer projects... 
  in a way that doesn't require LD processing
Manu Sporny:  We were very careful in how we designed Verifiable 
  Credentials spec to not require JSON-LD processing. I see a way 
  to use JSON-LD so it wouldn't impact you in a "now everybody has 
  to know it" perspective. With plenty of upsides like being clear 
  about semantics and shape of thing without being clear about it.
Manu Sporny:  You can still use framework of JSON-LD without 
  added complexity of processors. Other thing about proof. If you 
  use the ED___ verification thing, you're kind of asking for 
  interoperability pain down the road. But you can define your own 
  thing. If you want to create a WorkDaySIgnature2019 that didn't 
  use JSON-LD at all, you can do that today with the specs.
Manu Sporny:  You've got multiple people in the community who 
  would be happy to help with that. We've had 15 years of quite a 
  bit of iteration and design work in background.
Orie Steele: Related Ed25519 LD Suite Spec: 
  https://w3c-dvcg.github.io/lds-ed25519-2018/
Manu Sporny:  A couple other things. Gabe, don't know if it was 
  you or Joe or ... but a couple things said about semantics become 
  clear over time. That's problematic. The whole reason JSON-LD 
  came about is because semantics did not become clear over time, 
  and we had a bunch of systems bumping into one another. Whether 
  or not you buy into that, there are ways that reduce the chances 
  of interoperability concerns over time. There is a lot of really 
  great detail
Stuff to talk about here; community has some good answers about 
  how to generate interoperability over time. +1 from me.
Orie Steele: +1 For community to adopt work item.
Kim Hamilton Duffy: +1 To adopt work item
Gabec coworkers: one question, I did see in VCDM spec it points 
  to another vocabulary for linked data signatures. Not sure on 
  status of proposal or document. Says clearly that the type of 
  signature suite should be defined in that other document. You 
  said we were free to develop our own signature suite. Certainly 
  we can fit it in the data model, do we need to have a proposal 
  for disambiguating. If we're not using linkeddata it seems 
  inappropriate to submit
A scheme to that doc.
Dan Burnett:  A change in direction first... BTW this sounds 
  good; lots interested. This might be a premature question; just 
  want to make sure that you guys are comfortable that if this goes 
  into community group and into standards track, if you would have 
  any problems committing to a RF license for anybody who 
  implemented and made use of this?
https://openbadgespec.org/extensions/
Kim Hamilton Duffy is scribing.
Gabe Cohen: +Q
Nate Otto:  One example from past work of spec that has used 
  JSON-LD + JSON Schema... Extensions mechanism for Open Badges 2.0 
  [scribe assist by Manu Sporny]
Nate Otto is scribing.
Nate Otto:  We do have a variety of vendors and data interop 
  between them... developed own JSON-LD Context files and JSON 
  Schemas... pass through standardized verification mechanism... 
  it's possible to see that a badge has an extensions and get 
  semantic anchoring, which then references JSON Schema and method 
  for anchoring what part of the badge should be validated against 
  the schema. [scribe assist by Manu Sporny]
Nate Otto:  Works pretty well, we have some extensions that Badr 
  team that has done, others have also been successful at that 
  before. [scribe assist by Manu Sporny]
Anyone from Sovrin on this call? Doesn't Sovrin also have some 
  way to define credentials on chain?
Manu Sporny:  I think gabe asked with respect to LD signatures, 
  where do you define your own suite. Does it need to be in the LD 
  security context or can it be elsewhere? This raises the general 
  question of extensibility through registries and the type of 
  extensibility through JSON-LD. With JSON-LD you do it in a 
  decentralized manner; the registries are optional. The CCG 
  maintains them, but it's completely optional, because the 
  fundamental LD technology allows you
To extend in a decentralized manner.
Manu Sporny:  If you wanted to, you could extend in a way that is 
  a bunch of proprietary workday extensions; if you wanted to 
  produce your own signature mechanism, key format, etc, you could 
  do that without interacting with this community. If you want to 
  do it in a way that will not lead to interop conflicts in the 
  future, all you need to do is specify one context, the workday 
  context and put all your terms in there. Then you don't have any 
  conflicts and you can
Do whatever you want.
Manu Sporny:  It may get to the point where other people find it 
  useful and can pick it up. With decentralized extensibility, 
  nobody has to ask permission to do their own thing; but if their 
  own thing becomes useful to the community, we don't have to do 
  anything in the future if you do it with LD. Whereas without you 
  have to spin up a working group to standardize it.
Manu Sporny:  Summary: 1 option: do your own thing, don't worry 
  about interop. 2 option: super lightweight, just define your own 
  JSON-LD context, make it a URL and put it there at the top of 
  your documents; then Workday is not prevented by anyone in the 
  community, but you're guaranteed good interop in the future. 
  Option 3: Go all the way and implement JSON-LD deeply and be more 
  fully aligned with the ecosystem; your tools may be more deeply 
  pulled into the
Community. There are three enhancements. Hopefully that answers 
  where does it go question.
Kim Hamilton Duffy:  Thanks for presenting. Gabe on queue
Gabe Cohen:  We would love to be able to open source all of this; 
  working with legal to do that.
Manu Sporny: +1  For royalty-free desire :)
Dave Longley: +1 Thanks, great!
Gabe Cohen: Thanks for the feedback!
Orie Steele: +1 Thanks! :)
Kim Hamilton Duffy:  We are at time; thanks again. Great to have 
  the presentation. More discussions coming. We'll see you next 
  week.
Received on Tuesday, 22 October 2019 22:39:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:19:01 UTC