- From: <msporny@digitalbazaar.com>
- Date: Tue, 23 Jan 2018 13:25:18 -0500
- To: Credentials CG <public-credentials@w3.org>
Thanks to Chris Webber for scribing this week! The minutes
for this week's Credentials CG telecon are now available:
https://w3c-ccg.github.io/meetings/2018-01-23/
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 2018-01-23
Agenda:
https://lists.w3.org/Archives/Public/public-credentials/2018Jan/0067.html
Topics:
1. Introduction to Akila
2. Announcements, Focus for 2018
3. DID Harmonization
4. DID Hackathon Outcomes
Action Items:
1. Group needs to provide feedback on DID hardening PR by next
week Jan 30
2. Kim to clean up registry action items
3. Manu to write up Registry Process spec text still needed
4. Chairs to assign Joe as owner of CCG process
5. Chairs to assign Manu as Registry Process owner
Organizer:
Joe Andrieu and Kim Hamilton Duffy and Christopher Allen
Scribe:
Chris Webber
Present:
Chris Webber, Kim Hamilton Duffy, Akila Natarajan, Drummond Reed,
Manu Sporny, Joe Andrieu, Markus Sabadello, Christopher Allen,
Dave Longley, Christian Lundkvist, Moses Ma, Adrian Gropper, Ryan
Grant, David Chadwick, Ted Thibodeau, David I. Lehn, Kerri
Lemoie, Frederico Sportini
Audio:
https://w3c-ccg.github.io/meetings/2018-01-23/audio.ogg
Chris Webber is scribing.
Kim Hamilton Duffy: Let's review the agenda and then we'll get
to introductions and re-introductions
Kim Hamilton Duffy: I redid the agenda this morning
Kim Hamilton Duffy: Quick check-in on current action items and
work items
Kim Hamilton Duffy: Focus of the meeting will be any feedback
from open pull requests from DID hardening spec
Kim Hamilton Duffy: Finally we'll talk about refining some DID
hackathon bits
Kim Hamilton Duffy: And go through specific notes/questions
about BTCR
Kim Hamilton Duffy: Format of DID document, etc
Kim Hamilton Duffy: Any volunteers for
introductions/re-introductions?
Topic: Introduction to Akila
Akila Natarajan: I'm with ConsenSys we're working to build in
credentials, have been attending for the last couple months, a
few other participants from my team are on the calls
Kim Hamilton Duffy: Let's move on to announcements
Kim Hamilton Duffy: As we mentioned earlier as we went through
the work breakdown section, I think last week, we want to try to
give more structure to meetings, not just in terms of structure
of work items but also will help us when we talk about eg crypto
experts etc
Topic: Announcements, Focus for 2018
Kim Hamilton Duffy: For now I have announcements about upcoming
focuses for the next 11 months
Kim Hamilton Duffy: Next week we'll have the educational task
force present
Kim Hamilton Duffy: We've been breaking down issues in a github
issue
Kim Hamilton Duffy: We have Nate Otto and Kerry Lemoie joining
us
Kim Hamilton Duffy: Have been very active in the open badges
communities
Kim Hamilton Duffy: We'll be having Crypto Tuesdays, starting on
first tuesday of the month
Kim Hamilton Duffy: And review of digital verification suites,
including ld digital suites
Kim Hamilton Duffy: On february 13th we'll review Linked Data
Capabilities
Kim Hamilton Duffy: Implementor standup DID post-draft
Kim Hamilton Duffy: RWOT: https://rwot6.eventbrite.com
Kim Hamilton Duffy: Next RWoT is March 5-8 in Santa Barbara
Kim Hamilton Duffy: IIW: https://www.eventbrite.com/e/
Drummond Reed: What is the date/time of that "Implementer standup
DID post-draft"?
Kim Hamilton Duffy: Next IIW will be April 1-5th
Kim Hamilton Duffy: IIW:
https://www.eventbrite.com/e/internet-identity-workshop-iiwxxvi-26-2018a-tickets-39785360083
Kim Hamilton Duffy: At IIW, April 5-6 we'll have a post-IIW
Verifiable Claims face to face
Manu Sporny: Basically book your flights for an additional day
if you want to be at the F2F meeting... but you need to either
clear with chairs if not a w3c member, or be a w3c member
Joe Andrieu: Rebooting Web of Trust has a disc golf tournament
for those who can come a half day early. Please sign up ASAP to
help us make sure we have enough flying discs for everyone. Sign
up as an option on your standard RWoT ticket.
Drummond Reed: When you say leaving friday, will it bleed over
onto friday?
Manu Sporny: Probably
Kim Hamilton Duffy: Progress on action items, just wanted to see
if anyone has an action item they want to report status on, if so
add yourself to the queue
Manu Sporny: I'm having a hard time seeing... the registries are
done and out there, the DID spec is in a fairly good state right
now I think... I think we're going to talk about the DID spec in
a bit, but just wanted to note that Marcus has an outstanding PR
to resolve before we pull it in. current action item is to get
the DID hardening spec changes in there. Please look at it
people, we're going to pull it in soon
Kim Hamilton Duffy: Action item 5a: "W3C-CCG to complete
reconciliation of #RebootingWebOfTrust & Hardening changes (All,
due end of January)"
Kim Hamilton Duffy: So for action item 5a, this one you're
referring to, can I update to "the draft is in we need feedback"?
Manu Sporny: Yes, we should probably set a date to pull it in,
there's been decent discussion and implementation against
Kim Hamilton Duffy: What's a good date... let's see...
Joe Andrieu: Great, Drummond. Should be a fun time.
Manu Sporny: I'd prefer a week, it's been out there for a while
Kim Hamilton Duffy: Perfect, let's say we need feedback on the
DID hardening PR by next week
ACTION: Group needs to provide feedback on DID hardening PR by
next week Jan 30
Kim Hamilton Duffy: PR:
https://github.com/w3c-ccg/did-spec/pull/41
Markus Sabadello: Should we talk about my PR?
Kim Hamilton Duffy: How about during the DID hardening section
of the call
Markus Sabadello: Ack
Kim Hamilton Duffy: Manu, I'll follow up with you on registry
items submission etc... I think there isn't anything pending
Kim Hamilton Duffy: I'll take an action to clean up registries
ACTION: Kim to clean up registry action items
Christopher Allen: There is in the current action items the spec
text of the registry process needed
Christopher Allen: Needed to move back from the list to the
github
Manu Sporny: Can we make that just a separate action item?
Christopher Allen: There is currently, it's G
ACTION: Manu to write up Registry Process spec text still needed
Kim Hamilton Duffy: Let's move on to status of current work
items... we have 3... let's start with the CCG process
Christopher Allen: I put the first two here as there wasn't
really an owner, I mean the registry process I guess the owner is
manu as a work item, but we don't have an owner/lead editor for
the overall CCG process
Joe Andrieu: You can put my name on that one
Christopher Allen: Btw I'm in our next week, I'm editing action
items document (?)
ACTION: Chairs to assign Joe as owner of CCG process
Kim Hamilton Duffy: JoeAndrieu said can assign owner of CCG
process?
Joe Andrieu: Yes
ACTION: Chairs to assign Manu as Registry Process owner
Kim Hamilton Duffy: Lastly we wanted to check in on Verifiable
Claims browser polyfill
Dave Longley: Yes we need to talk to Google's team... no major
progress lately or feedback on what people would like to see on
query mechanism on issues
Dave Longley: If you have feedback, please provide it on IRC
Kim Hamilton Duffy: Thanks dave.. let's move on to DID hardening
PR
Dave Longley:
https://github.com/w3c-ccg/credential-handler-api/issues
Topic: DID Harmonization
Kim Hamilton Duffy: Hardening PR:
https://github.com/w3c-ccg/did-spec/pull/41
Manu Sporny: I think that the update to the DID spec wasn't too
difficult, reflects what I believe is where we got on nearly
everything... some sections I needed to comment out, like
delegation, which we haven't figured out yet, and authorization
will go into method specific specs
Manu Sporny: Preview link is here:
https://pr-preview.s3.amazonaws.com/w3c-ccg/did-spec/pull/41.html
Manu Sporny: Diff-marked version is here:
https://pr-preview.s3.amazonaws.com/w3c-ccg/did-spec/pull/41.html
Manu Sporny: Please look and review and make sure you're happy
with it
Manu Sporny: Hopefully not controvercial because it's what
everyone has agreed to... markus_sabadello has come up with a
useful PR giving updates to some parts of the spec... other than
those 2 things if we get that pulled in, we'll be in a good place
to nail down more parts of the implementation
Manu Sporny: One thing to note is people are implementing
against the spec now
Markus Sabadello: My PR:
https://github.com/w3c-ccg/did-spec/pull/43
Kim Hamilton Duffy: Thank you... markus_sabadello do you want to
talk about your proposed changes?
Markus Sabadello: Yes like Manu said it's updates about the
examples... some examples didn't have the services properties
array, so I updated them to have the service array
Markus Sabadello: Most of the changes fix a lot of simple bugs
which were not controvercial
Markus Sabadello: I was wondering about what examples for
service endpoints... I wonder what examples for openid service,
etc... in harmonization were using all sorts of service examples
Markus Sabadello: So I ??? without explaining what it was
Markus Sabadello: I added a lot of examples of whatever specific
examples, including openid auth, social web inbox service
Markus Sabadello: And I think all the other changes shoud be
non-controvercial
I was wondering about the service types a bit
Markus Sabadello: In RDF / json-ld the format typically uses
UpperCase resource names
Markus Sabadello: So some of the recent examples used lower case
Markus Sabadello: So that's what I was addressing in there
Kim Hamilton Duffy: I see no comments in the queue... from the
DID hackathon last week, we were using it and the updates looked
great... only feedback we had which we're not proposing to block
on was to add more examples
Kim Hamilton Duffy: That's something that I can take a stab at
as we get feedback on BTCR examples as well
Manu Sporny: +100 To more people doing PRs againstn the spec.
Kim Hamilton Duffy: Aside from that, it was great
Christopher Allen: I wanted to appreciate the work that
markus_sabadello has been putting in to normalize names and etc
and do some cleanup on examples
Christopher Allen: In particular I was looking at endpoint types
and etc and ran into something related which we were talking
about w/ BTCR... BTCR specifies a particular kind of endpoint. I
wonder if there are other DID methods that are also specifying a
specific endpoint or something? does Veres One have something
very, very specific? does ViewPort, etc?
Drummond Reed: To answer ChristopherA's question, can only speak
for Soverin, can't say it'll be required but there will certainly
be a standard Sovrin endpoint
Drummond Reed: As we complete the Sovrin DID method spec it may
turn out it's necessary to control auth, etc
Drummond Reed: I haven't seen that yet... but it doesn't
surprise me... I can only speak for Sovrin and not others
Christopher Allen: Christian
Christian Lundkvist: Speaking for uPort, we'll probably have a
backup endpoint, but still being worked on
Manu Sporny: Veres One doesn't have a specific endpoint so far,
we were trying to point to other specs... nothing Veres One
specific
Manu Sporny: I agree with Markus
Dave Longley: +1
Markus Sabadello: To be honest I'm surprised that some DID
methods support/require some service endpoints that others don't
Moses Ma: Can someone share if there's a DID testnet? We'll start
implementing a prototype using DIDs soon.
Christopher Allen: Your concern is exactly one of my feeling
weird about the endpoints... in BCTR we have only one 40 byte,
sometimes 80 byte field to refer to the DID document. We're in
effect saying that "here is the place to begin to construct the
DID document", as in terms of a standard URL it may have more
stuff in the static object, or in case of IPFS it may be only one
of several things that have to be grabbed. But it could also be
where we put in issuer date, etc as well... I'm confused if we
had a very specific BTCR function, but maybe it could also store
other verifiable claims that other people could grab
Christopher Allen: Should we specify in a generic way that
"here's an endpoint with a static bag"
Christopher Allen: Whether we had two endpoints... etc... it
just felt weird
Christopher Allen: I just wanted to get a feel for what other
people were doing
Adrian Gropper: I like to think in terms of what's public and
what will be indexed by various entities and what is not strictly
public. the endpoint that matters to us is the one that points
to the authorization server related to that DID
Ryan Grant: IOW, the patch files (often retrieved over IPFS)
which are used to create a DID Document by the method handler may
also include other verifiable claims and such that are not
patched into the DID Document.
Adrian Gropper: Agency that derives the ??? and the other one is
the agency that has to ?????? credentials for private information
Adrian Gropper: I think the issue of an authorization server is
fairly general so we might consider it
Ryan Grant: Above was for markus_sabadello [scribe assist by
Ryan Grant]
Christopher Allen: I think this is all worthy of next draft
Kim Hamilton Duffy: I think that was a good transition to the
BTCR topic
Manu Sporny: +1 To dealing w/ this stuff /after/ we get a stable
draft based on harmonization/hardening changes.
Kim Hamilton Duffy: Reminder that you have a week to get to the
outstanding DID spec
Drummond Reed: By "next draft", is ChristopherA referring to the
next draft of the DID spec or of the BTCR DID Method spec?
Christopher Allen:
https://hackmd.io/CYI2wVgDgZhBaCA2CAGeAWKSbwIZQDsw+AxgGYTAYCmAnHiuUA==?both
Topic: DID Hackathon Outcomes
Kim Hamilton Duffy: We'll start with Veres One then move to BTCR
Manu Sporny: Want to cover anything with Veres One?
Manu Sporny: So most of the hackathon, unfortunately didn't get
as much time we wanted to, we looked at the DID spec to make sure
it works, also work on Christopher Webber did on the linked data
object capabilities spec, also working on updating the DID client
to handle the current DID spec. nothing bad to report so far,
everything seems like it will work out, but we'll learn more as
we finalize our implementation
Kim Hamilton Duffy: To move on to BCTR I think most of what we
did was mostly work on the example of the generated DID Document
that generated from the combination of transactions...
combination of making the output to the latest version from the
DID hardening process
Kim Hamilton Duffy: We had some thoughts/questions about
resolvers
David Chadwick: Present +
Drummond Reed: Very quickly because I have to jump off before
the end of the call, we also like everyone else were saying "well
now that we have a hardened DID spec we need to work on the
Sovrin DID spec... key management is a major piece of what a DID
spec method does, so I expect it'll mature a lot over time with a
pretty robust set of changes post-?rebooting
Drummond Reed: We'll also have an update for (DKMS?)
Christopher Allen:
https://hackmd.io/CYI2wVgDgZhBaCA2CAGeAWKSbwIZQDsw+AxgGYTAYCmAnHiuUA==?both
Ryan Grant: Cleaner look from this url:
https://hackmd.io/CYI2wVgDgZhBaCA2CAGeAWKSbwIZQDsw+AxgGYTAYCmAnHiuUA==?view
Drummond Reed: Yes, we'll have an update on both the Sovrin DID
method spec and DKMS (Decentralized Key Management System) by
Rebooting the Web of Trust the first week of March.
Christopher Allen: I'll put the URL again... this was the
document we were working on. so one of the things we discovered
was we needed to go back... what things were happening, what's
the process... if I get a DID document I need to resolve I might
have to go to the BTCR specific sub-resolver and it has to do
something specific to return back to the app. So we looked into
what happened there... some were BTCR specific and some may be
relevant to others
Christopher Allen: The BTCR resolver has to create an "implicit
DID document" solely from the bitcoin blockchain data which may
not be everything. If people want to know some extra values
there we have an audit trail tag. one thing the BTCR method does
is go to the BTCR endpoint to get the first json type DID
document. So what it's going to do is go there
Christopher Allen: There's a sub-note here in that the ID, the
BTCR number, may not actually be in that DID document because it
may be an immutable filename by a content hash. There's a
catch-22 in that there's some information we can't put in there.
So the BTCR endpoint has to construct the id when it's creating
the final DID document back to the app
Ryan Grant: Stated more narrowly: the DID "ID" may not be in the
pre-compliant patch used by the method resolver to construct a
fully compliant DID Docuemnt (diddo), which will by then actually
have the "ID", and other known values.
Christopher Allen: So the next thing the DID resolver does is
validate that the json-ld document is valid. If it's ??? it's
implicitly part of the graph because it's signed by bitcoin.
Bitcoin has the public key, the hash, we don't have to it again.
If the BTCR thing has to call it again we may have to do it
again. This raises the question, is there a standard way to
refer to the bottom-most key in a DID. Finally the resolver
grabs and resolves known DID documents into the final DID
document value, but we explicitly say you cannot overwrite the
DID value, it's addative only
Christopher Allen: If there are other json-ld values we don't
know about, such as somebody else may be referring to the same
DID document, since IDs are constructed by the resolver and
Etherium could sign it, maybe they both point to the same value
Christopher Allen: Because of IPFS we may have to pass in
additional DID document material
Christopher Allen: That part the resolver ignores and we return
the final DID docuemnt
Christopher Allen: We have an example of what it did
Christopher Allen: We have a json structure in there
Christopher Allen: One of the things we had was a
resolver-specific envelope
Christopher Allen: The resolver can do satoshi-audit-trail, say
what the resolver did to resolve the DID document, etc
Christopher Allen: Then we have the public key which comes from
the bitcoin transaction, by default the transaction is only that
id, we refer to the service audit etc
Christopher Allen: We refer to the Satoshi id as the ??
Christopher Allen: This raised some questions, why would an app
need to know about updates
Ryan Grant: SatoshiAuditTrail
Christopher Allen: The DID resolver has to see if there are
updates etc
Christopher Allen: It will keep on doing that until it has the
proper DDO
Christopher Allen: Why would an app ever need that
Christopher Allen: If it is going through old DDOs to get to the
current DDO, is this an audit trail, what layer is it happening,
etc
Christopher Allen: Our other big open question is the timestamp
Christopher Allen: A bunch of other things timestamped by the
bitcoin transaction
Christopher Allen: Not a bunch of timestamps on the DID document
as a whole
Christopher Allen: Btw because it's constructed there's no ???
as a DID ?? as a whole, relying on the resolver to assume it's
correct
Christopher Allen: Since it's not the issuer it can't sign the
DID document as a whole
Kim Hamilton Duffy: No signature on the DID as a whole ^^
Christopher Allen: We have some ideas a document extensions
Markus Sabadello: Do you have a pointer to your resolver
implementation ?
Christopher Allen: With other BTCR documents, we're ignoring
those
Christopher Allen: That's the summary of our thought process
Chris Webber: There's no owner signature enveloping the whole
returned DID Document (diddo) [scribe assist by Ryan Grant]
Christopher Allen: Did we miss something, do something wrong
Drummond Reed: Sorry, must leave early today. Will make sure that
Evernym and Sovrin folks provide input on DID draft this week.
Ryan Grant: I put myself on the queue before ChristopherA got to
the updates
Ryan Grant: For people familiar with the DID hardening spec and
status of the update field, what's going on there
Kim Hamilton Duffy: Marcus is next, I noticed your question on
irc... we're just talking through the steps of what we would
expect a resolver to do... I'm looking forward to hearing your
feedback
Drummond Reed: What's the "update field"?
Kim Hamilton Duffy: @Drummond it's the transaction output, which,
if spent, says go to the next tx in the chain to find updates
Markus Sabadello: I did some earlier work on BTCR... what we've
been calling ??? we've been calling drivers(??), what you've been
calling ??? we've bene calling envelope?
Markus Sabadello: I think this would be metadata, on the
envelope, rather than being on the service endpoint, method
specific, not really an endpoint one would interact with,
metadata of the resolution process rather than ending up in the
final DID document. other than that I think the link you posted
with the resolution steps is super helpful
Kim Hamilton Duffy: One point before I move to the next person
on the queue
Manu Sporny: Just wanted to provide thoughts to the markup...
the first thing I think ChristopherA pointed out was that the
BTCR endpoint might be able to be moved to signature / audit
trail in some way
Manu Sporny: We've been calling this... based on the last RWoT
we had request from u-port / evernym folks to not put that in
there, say that's DID method specifc, so that could be specified
by the BTCR method in the spec
Christopher Allen: One of my open questions is... the DID
document you give an app which says "please resolve this DID",
should the app ever give the authorization things? that's for
something else, that's for determining whether the DID was
authorized, and it is or isn't
Christopher Allen: It almost feels like two different things
here
Manu Sporny: I may be missing a nuance
Ryan Grant: Markus_sabadello, the idea of the BTCR endpoint,
it's not a required endpoint but it's something that will
probably be available because of the way the DID documents are
???
Ryan Grant: Ie it means if finding something through IPFS it
would be this is the URL you can go to in IPFS to collect some
other verifiable claims that a BTCR method resolver would be very
good at parsing through and perhaps other clients would be able
to read, but it's not a required thing
Ryan Grant: Does that sound like a good use of a service now?
Markus Sabadello: Sounds more like a service now that you've
described it
Markus Sabadello: It's a service endpoint in the DID document,
it's metadata... in the envelope rather.. I'm undecided
Ryan Grant: My understanding is the purpose, one of the 3 main
purposes, is to retreturn services
Ryan Grant: Is that wrong?
Christopher Allen: Other way to approach this, redefine a
service, a static json-ld service with json-ld objects, and if
one of those json-ld documents is a DID document, others should
probably just ignore it. can define a static endpoint which
points to a single file or single json object, some bag (?) from
which BTCR uses it to get (???) but others can use it to find
what to put in that bag
Christopher Allen: So the spec for that bag may store some
method-specific things in here as well
David Chadwick: This is not on the current agenda, on previous
agenda, but unfortunately I missed it... there was an item on the
agenda for me to review the current spec w/r/t lifecycle, so I
sent outt an email listing what I thought was missing from
current DID document
David Chadwick: What should I do? I didn't do it initially
because I was looking for feedback before PRs
Christopher Allen: I think it's up to you if there's a pull
request or an issue... a number of them felt like whether you had
some questions about it, or even whether you had your own
questions about it, which may be seaparate issues. I don't think
anyone's going to complain about it, can make specific PR
requests about it. Manu, as the editor of the current DID
document, does that make sense?
Manu Sporny: I missed a lot of what you said, let me read and
I'll respond on IRC
Manu Sporny: Yes, that makes sense... do some PRs
Christopher Allen: Ok! back to BTCR hackathon observations
Manu Sporny: We can sort it out in an issue or the PR
Christopher Allen: Are any other methods having to reconstruct
the DID Document in some way? Does viewport have to do that
where it's in fact in various pieces and then constructed?
Manu Sporny: I suggest folks don't let the spec slow them down as
long as there is a solid plan for interoperability via a PR at
some point in the near future.
Kim Hamilton Duffy: This is Christian_Lundkvist speaking
Christian Lundkvist: We had same issue with DID document, where
DID object is the object's hash, so that document can't be the
final DID document because it contains the id which has the hash
of the document... same issue ChristopherA described. I think
we've been thinking of doing the same thing where DID document
does not produce the same document, it's up to resolver to make
sure everything is valid
Kim Hamilton Duffy: I think action items for next week is to
make sure DID resolver document is valid
Kim Hamilton Duffy: We'll find the right way to follow up
Kim Hamilton Duffy: We have two people on the queue
Christopher Allen: I just have an open question for manu /
dlongley ... we have this json DID object which some pieces are
timestamped, some of them are provably timestamped... some
aren't... some are signed in one way some are signed in another
way... how do we refer... how do we do that in json-ld?
Christopher Allen: The time signatures spec was for the object
as a whole, so are most of the other signature things... how do
we do when "this value, this value, and this value we signed by
the eterium blockchain, this value and this value were signed by
this key which we got from the blockchain but isn't signed on the
blockchain, this and this are implied from data we got
elsewhere..." how much of that do we actually have to put in?
Christopher Allen: Seems like the resolver / driver needs to do
some, how much of it has to be delivered to the app? I'm not
sure they're the same
Dave Longley: It may be as simple as the resolver signing and
saying it did all those checks -- it's only important to try and
represent all of that data if someone else can do the same checks
Christopher Allen: We don't need an answer now just would like
you to think / give thoughts
Markus Sabadello: Wasn't too important and we're at time
Dave Longley: Could be done by specifying a JSON-LD frame in the
signature data, but like manu said, can get messy/hard to
understand.
Manu Sporny: Just quick ChristopherA, the short answer is we can
do whole object signatures, set signatures, chain signatures, as
long as it's the whole object. We can do different signatures
today. Doing the cherry picking signatures, that requires a new
mechanism, we've avoided it because it really complicates
situations and creates possibiltiy of security vulnerabilities
where developers assume the object is signed where it may not be
signed at all. I'm very hesitant, we've done that before for
http signatures, but it's kind of a landmine when you do that
Manu Sporny: Short thoughts, we can discuss more later
Kim Hamilton Duffy: We'll follow up on that... we can have an
audit trail to check that, but I agree once it's in there there's
an issue where there's an expectation that it's fine. I'll
follow up with BTCR folks to see what they think
Kim Hamilton Duffy: Questions around resolver, specific schemas
Kim Hamilton Duffy: Thanks all
Received on Tuesday, 23 January 2018 18:26:08 UTC