- From: <kimdhamilton@gmail.com>
- Date: Tue, 22 Oct 2019 15:39:24 -0700
- 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