- From: <kim@learningmachine.com>
- Date: Fri, 15 Mar 2019 20:12:55 -0700
- To: Credentials CG <public-credentials@w3.org>
Thanks to Manu Sporny for scribing this week! The minutes
for this week's Credentials CG telecon are now available:
https://w3c-ccg.github.io/meetings/2019-02-19/
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-02-19
Agenda:
https://lists.w3.org/Archives/Public/public-credentials/2019Feb/0031.html
Topics:
1. Introductions/Reintroductions
2. Announcements
3. Action Items
4. Review ABNF PR
Organizer:
Christopher Allen and Joe Andrieu and Kim Hamilton Duffy
Scribe:
Manu Sporny
Present:
Andrew Hughes, Markus Sabadello, Kim Hamilton Duffy, Vaughan
Emery, Moses Ma, Heather Vescent, Jonathan Holt, Joe Andrieu,
Christopher Allen, Amy Guy, Dave Longley, Dmitri Zagidulin, Ted
Thibodeau, Ken Ebert, Ganesh Annan, Brent Zundel, Manu Sporny,
Samantha Mathews Chase, Drummond Reed, Jeff Orgel, Adrian
Gropper, Michael Herman
Audio:
https://w3c-ccg.github.io/meetings/2019-02-19/audio.ogg
(Will join audio shortly, VCWG is still wrapping
@Achughes don't trust me, trust the blockchain
Kim Hamilton Duffy: https://w3c-ccg.github.io/meetings/
Kim Hamilton Duffy:
https://lists.w3.org/Archives/Public/public-credentials/2019Feb/0031.html
Manu Sporny is scribing.
Topic: Introductions/Reintroductions
Kim Hamilton Duffy: Anyone new on the call?
Kim Hamilton Duffy: No one new, let's move on to
reintroductions.
Jeff Orgel: Hi, Jeff Orgel, professional appreciator and
technologist in St. Louis, MO.
Jeff Orgel: Been watching this group work through this -
typically a bystander, but don't quite undrestand language/nuance
- don't know if I'm qualified there, but been a technologist 27
years, put first computers on shelves in Best Buy... digital
anthropologist, try my best to do what I can to help.
Topic: Announcements
Kim Hamilton Duffy: Big announcement! We're adding Markus to the
list of Editor's on the DID spec.
Samantha Mathews Chase: Congrats!!
Markus Sabadello: Thank you!
Kim Hamilton Duffy: https://w3c-ccg.github.io/announcements/
Joe Andrieu: Thanks, Markus!
Manu Sporny: Thank you for volunteering, Markus! :)
Dave Longley: +1
Kim Hamilton Duffy: http://rwot8.eventbrite.com
Kim Hamilton Duffy: RWoT8 is in Barcelona, Early Bird discount
is over... regular ticket prices open until Feb 22nd.
Andrew Hughes: 57 People are registered now for RWOT 8 in
Barcelona
Christopher Allen: RWoT8 has about 30 advanced topic papers
submitted, 7-8 on DIDs, 4-5 on VCs, 3 so far on social key
recovery, quite a few other topics... GDPR, SSI, etc.
Andrew Hughes: Prices go up on February 23 (due to catering order
deadlines)
Kim Hamilton Duffy: VCWG F2F
https://github.com/w3c/verifiable-claims/tree/master/f2f/2019-03-Barcelona
Christopher Allen: Highly encourage you to go to Github and take
to topic papers, even if you're not going to RWoT.
Joe Andrieu: 57? Wow. Big group, even with the last minute venue
selection. That's awesome.
Christopher Allen: We're not going to be having meetings next
week or week after... Chairs are going to be on their way to
RWoT.
Christopher Allen: The week following, unclear, we may not be
doing CCG meeting... all Chairs are flying or at VCWG meeting in
Barcelona.
Kim Hamilton Duffy: Thanks Christopher, we will be flying in
separate planes to reduce the "bus factor"
Kim Hamilton Duffy: https://www.internetidentityworkshop.com
Kim Hamilton Duffy: IIW April 30th - May 2nd - in Mountain View
Ken Ebert: Nice theme music!
Kim Hamilton Duffy: We will have a few BTCR folks Barcelona...
we will have a pre-BTCR kick-off.
Kim Hamilton Duffy: Ping me if you are interested in the BTCR
meet up
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/44 is waiting, I
think we're trying to assign someone there.
Woops, scribe meant 43
Manu Sporny: Issue 59 is talking about that there are a copule
of DID methods that did not have a spec attached to them, in some
cases we were promised them and they never came. We've asked them
to submit a spec, many responded. If peopel continue to not
provide specs (can be two paragraphs that you will update over
time) then do they get to stay in the registry [scribe assist by
Amy Guy]
Amy Guy: ... Already got confirmation from a number of people.. I
do'nt know if there's any further action to take, other than
revisit in a month to see who still hasn't done that
Kim Hamilton Duffy: Yes, we don't need to talk abou tthis every
week, but will check back in in a while.
Drummond Reed: I believe that the requirement should now become
that a new method is not accepted until the registrant has a
method spec.
Drummond Reed: It's okay if the spec is changing; almost all the
DID method specifications are still evolving.
Jonathan Holt: Yes, these are still early days, many of the
specs are changing rapidly, difficult to support something that's
changing quickly.
Jonathan Holt: What is the formality of this registry process?
Ledger process?
Kim Hamilton Duffy: Publishing that document is just
informational, doesn't have to be in line/supported.
Drummond Reed: All DID Method specs are evolving, may need to
raise bar to you need to at least provide document for DID Method
spec.
Drummond Reed: The last thing we want is a name grab.
Christopher Allen: Yes, similar - you don't have to implemented
the spec, just that there is a place where people can go and get
things, who is doing what -- what are general thoughts on how it
works, how to get on a mailing list... doesn't mean you need to
have implementations, doesn't mean you need W3C IPR, it's
supposed to be a lightweight thing.
Drummond Reed: +1 To Christopher's point that the spec does not
have to have been implemented. Just that you have published a
spec in someplace where it can be viewed.
Christopher Allen: Part of it is to avoid "centralized registry"
-- too soon to try to create "decentralized registry" to register
dozen or so real DID Methods.
Christopher Allen: Maybe we will have lightweight registries
like that in the future, the requirements are light, we can't
have just everyone squatting on names... have to be serious
enough to begin draft.
https://w3c-ccg.github.io/did-method-registry/
https://w3c-ccg.github.io/did-method-registry/#the-registration-process
Manu Sporny: +1 To everything everyone just said. We outline the
registration process in the registry and we do say that you have
to create a spec. Like Christopher mentioned, the spec does not
have to be complete or implemented, but you do have to give
general guidence on what you're trying to do [scribe assist by
Amy Guy]
Amy Guy: ... Mots of the ones that are there are going to submit
in the near future
Drummond Reed: Also, this registry is *informal*, for the benefit
of the community, and has no formal authority.
@Drummond that's not true, the formal authority is whoever has
write access to the git repo
Amy Guy: ... The other thing is that this became an issue because
people said they want to be in the registry but the spec is going
to be 6 months from now. We need to take a stance against stuff
like that, as weeks roll on, some companies are clearly trying to
name squat on the registry. We want people who are actively
implementing this stuff
Markus Sabadello: I've been in touch with Jolocom and they're
planning to submit a method spec soon.
Drummond Reed: @Justin_R I meant "standards based" authority.
Yes, it does of course have access permissions in github.
Joe Andrieu: It's the name squatting that's a problem, if people
can grab a name and sit there, that's not good -- write a spec is
the minimum bar.
Topic: Review ABNF PR
Joe Andrieu: Dmitri put together a PR addressing a variety of
issues, which is not addressing my issue. So let's have him
start, and then go to me.
Ganesh Annan: What's the link to the issue and PR?
Amy Guy: https://github.com/w3c-ccg/did-spec/pull/168
Dmitri Zagidulin: That PR integrates a bunch of different
conversations in issues/PRs/calls - some confusion the
relationship between service references, links to services that
require intermediate DID resolution and the DID URIs themselves.
Ganesh Annan: Thank you rhiaro
Dmitri Zagidulin: The PR clarifies the ABNF rules to define some
of the undefined terms, splits the ABNF rules into two sections,
one dealing w/ just DID URIs, and another wrt. DID References on
top of those URIs... key identifiers, links to service paths and
queries and such.
Joe Andrieu: Yes, thank you for putting that PR together, Dmitri
Joe Andrieu: https://github.com/w3c-ccg/did-spec/issues/170
Joe Andrieu: When I read through the PR, it wasn't quite
addressing my first "crazy makin' face" -- two concerns that I
have:
Joe Andrieu: Every concept I've had is DIDs as URIs/URLs - which
include the entire string.
Joe Andrieu: Looking at the WebChat interface right now, there
is one string, URL - includes scheme, authority, query, fragment,
etc.
Joe Andrieu: So, DID scheme and identifier string was what we
focused on and that was confusing.
Michael Herman: DIDs aren't comparable
http://irc.w3.org/?channels=ccg
Joe Andrieu: Struggling to see how proposed distinction actually
works w/ the URI stuff.
Michael Herman: The latter is a query against a website
https://tools.ietf.org/html/rfc3986
Joe Andrieu: There is the hierarchical part and the rest...
maybe we can get away with customizing the hierarchical parts in
a traditional URL.
Joe Andrieu: I proposed a strange quirk, no consensus around it
- seemed to me that the query part is a good place to put the
service
Joe Andrieu: So, move service to query part, would like feedback
on that.
Joe Andrieu: If you have a DID w/ a query on that, what are the
semantics? What about paths?
Drummond Reed: When I saw the thread, I do understand what
JoeAndrieu is getting at...
Drummond Reed: I discussed this w/ Markus, the evolution of the
term DID has always corresponded to actual identifier that is
"resolved"
Drummond Reed: In order to get the DID Document. From the
outset, we used the term DID for that - we wrote the ABNF around
that - the DID Identifier... we've never formally come up with
the term... for... that identifier by itself is a URI. it is
technically a URL, because it can be dereferenced.
Drummond Reed: DID identifier, by itself, is a URL.
Drummond Reed: We've never come up with a formal name, we had
something in ABNF, add path/query/fragment - then you have a DID
URL... something that is more than just the DID.
Drummond Reed: That's why DID didn't correspond to same thing
that URI/URL does.
Drummond Reed: We may want to say DID-URL is something beyond
just the identifier.
Michael Herman: +1 For drummond's comments
Drummond Reed: For service IDs, how we select a service, this is
the fourth identifier/discovery spec I've worked on - what we
discovered in XRD work was that we had the same challenge there,
we had a syntax for putting service identifiers in query
components, but it was a nightmare to implement.
Drummond Reed: The problem is in order to create URLs that
resolve to services, you want to reserve everything after the
service -- pass on everything as it is composed.
Drummond Reed: It is much simpler to put service ID selector as
component of hier part, before path query or fragment.
Drummond Reed: There are only a few characters you can use to
distinguish that component.
Dave Longley: +1 To the above
Drummond Reed: I'm happy to go deeper, Markus can explain
challenges.
Dmitri Zagidulin: Excellent points, want to address a few of
those.
Dmitri Zagidulin: Putting service in query is something that was
discussed, that's one of the things that has been brought up
multiple times - implementation experience that drummond
mentioned, goes against various subtleties of URI spec, so, "no"
on "let's put it in the query part"
Dmitri Zagidulin: Current PR that is being discussed, uses exact
same term... DID URL -- instead, uses DID Service Reference.
Drummond Reed: Here is the link to the OASIS XRD (Extensible
Resource Descriptor) spec:
http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html
Joe Andrieu: Q to ask how does using query as service violates
3986
Dmitri Zagidulin: Unlike traditional URLs, DIDs, since they are
based on distributed ledgers, DHTs, there is no server on the
other end to execute a query... that's why it doesn't make sense
to semantically have a query to the DID itself.
Dmitri Zagidulin: The only context where paths/queries make
sense is in reference to the service inside the DID.
Dave Longley: And they are method independent! :)
Dmitri Zagidulin: That's where the current PR is... that's why
we make a sharp distinction between this is a DID and this is a
DID Reference.
Jonathan Holt: Curl -s
https://ipfs.io/api/v0/dag/get?arg=zdpuB1oR3vjYmkDc9ALfY7o6hSt1Hrg2ApXaYAFyiAW5E4NJP
Jonathan Holt: In the IPID spec, we use IPLD, we have RESTful
endpoints behind the scenes, gateway, cloudflare, etc... that
dereferences the key attribute, DID method specific identifier to
CID
Jonathan Holt: Curl -s
https://ipfs.io/api/v0/dag/get?arg=zdpuB1oR3vjYmkDc9ALfY7o6hSt1Hrg2ApXaYAFyiAW5E4NJP/previous
Jonathan Holt: Curl -s
https://ipfs.io/api/v0/dag/get?arg=zdpuB1oR3vjYmkDc9ALfY7o6hSt1Hrg2ApXaYAFyiAW5E4NJP/previous/previous
Jonathan Holt: Curl -s
https://ipfs.io/api/v0/dag/get?arg=zdpuB1oR3vjYmkDc9ALfY7o6hSt1Hrg2ApXaYAFyiAW5E4NJP#key
Jonathan Holt: The beauty of that, use slashes to represent path
traversal, you could get previous version of DID Document, to get
all the way back. We don't use DID fragment, that's coming from
HTML protocol, fragment in DOM.
Jonathan Holt: Curl -s
https://ipfs.io/api/v0/dag/get?arg=zdpuB1oR3vjYmkDc9ALfY7o6hSt1Hrg2ApXaYAFyiAW5E4NJP#alfjalkfjaljdoifuaoiufoiaudfouaofduaouasoiufsaoduf
Jonathan Holt: Echo what Dmitri said, some concern - pseudo like
URI, but we're carrying over the query language that is focused
on HTTP protocol. In some cases we use the hash as a secret share
to decrypt the payload.
Michael Herman: This always gets so complicated, reiterate
something I said a bit ago - this whole query part, everything
that comes after identifier, should be removed to DID Resolution
specification.
Michael Herman: I feel like we never are going to get to the end
if we keep talking about protocol stuff.
Michael Herman: That being said, drummond and Joe engaged in a
discussion around the ABNF - Drummond proposed something... very
clean separation between DID and DID string... we've come a long
way in separating what the identifier is, we just need to make
sure we don't lose that.
Markus Sabadello: The DID is just the idnetifier itself, if we
have path/query/fragment, then it's something else... DID
Reference, DID URL, or something else.
Markus Sabadello: It helps to be clear on what we're
dereferencing. I think the way Dmitri has explained it, when you
dereference, the DID reference, then you either get resource in
DID Document or to service endpoint.
Drummond Reed: -1 To "removing everything but the main DID
identifier from the DID spec". The treatment of how paths,
queries, and fragments are resolved is IMHO core to how DIDs can
be used. Furthermore, the syntax for that is defined in the
"hier-part" of the identifier (from the URI ABNF), so it really
needs to be in the DID spec.
Markus Sabadello: Wonder if DID Resolution spec should be called
DID Dereferencing spec... don't think ABNF should be in DID
Resolution spec, but think Dave has explained it in a convincing
way to separate data model and syntax from protocol.
Michael Herman: Here's a link to the issue I and Dimitri are
discussing:
https://github.com/w3c-ccg/did-spec/issues/166#issuecomment-464502719
Markus Sabadello: With respect to service name, I don't think
that should be in query string, don't know if that's what we're
proposing, advantage of doing that, service name would be a
resource in the RDF graph, in JSON-LD... so, service name isn't a
query, it's an identifier of the resource that represents the
service in the DID Document.
Drummond Reed: +1 To identifying the service-id in the
"hier-part" so it does not interfere or complicate a path, query,
or fragment.
Manu Sporny: Two things, one - having a bit of a problem
following the discussion [scribe assist by Dmitri Zagidulin]
Dmitri Zagidulin: … It would help to actually look at the various
proposals side by side
Dmitri Zagidulin: … Not that this conversation is not useful, we
just need to get on the same page
Dmitri Zagidulin: … Regarding calling something a "DID Reference"
vs a "DID URL" — the problem is that the DID string itself is a
valid url
Dmitri Zagidulin: … So calling something /else/ a did url (what's
being referred to now as a did service reference) might confuse
the TAG and others
Kim Hamilton Duffy: If we could discuss at RWoT or have a
proposal w/ some ABNF in it, that would be helpful.
Joe Andrieu: I'm trying to understand the service identifier in
the "hier" part so it doesn't stomp on the path or query.
Joe Andrieu: Query and path seems to have no meaning
Joe Andrieu: Dmitri said use of query might violate RFC3986, so
would like to hear more.
Joe Andrieu: I want to say "this service endpoint is how you
reach me", and I'm going to put a DID there...
Joe Andrieu: Or, I say, here's my public key, get it from my
DID, and the key will apply to the fragment.
Joe Andrieu: I'm having a hard time understanding the
nuances/distinctions, users aren't going to understand that...
people will just say "DID starts with did: and that's it"
Christopher Allen: My issue is, looking from developer
perspective, I'm the equivalent of a browser or curl or some
other network-enabled application.
Drummond Reed: Again, that's another reason in my mind to
establish the term "DID URL"—and use that all time to refer to a
DID used as a URL.
Christopher Allen: When I ask for a traditional URL today, when
I hit the "#" character, everything after that is for the client
to process.
Christopher Allen: What I'd like to see in our spec is what the
ultimate end client has to do themselves, which to me is after
the "#" sign.
Christopher Allen: For example, keys... vs. what the resolver
does - resolver doesn't do parsing, right?
Drummond Reed: The DID spec is already very clear about how to
handle a DID URL fragment.
Christopher Allen: Resolver gives DID Document.
Christopher Allen: As for what the resolver -- the resolver may
handle the "?" stuff
Christopher Allen: If you are asking for "?" things, you're
getting a subset, need to understand distinctions.
Christopher Allen: With BTCR, it's a service that cannot give
you the data... Bitcoin core isn't going to give you a DID.
Christopher Allen: There will be other services where you need
an intermediary.
Dmitri Zagidulin: Addressing a couple of the points...
Ted Thibodeau: An HTTP/S server doesn't receive anything from the
# to the right. (other URI schemes may handle the # differently)
Dmitri Zagidulin: It's important to distinguish the URL of
interacting w/ resovler, service reference... what jonnycrunch
was describing wrt. resolver, that's important because it'll
differ from resolver to resolver.
Ted Thibodeau: The fragment separator ("#") and everything beyond
it is strictly client-side, for instance, inside the web browser
Dmitri Zagidulin: The parameters passed in query to resolver,
that's one thing - we will talk about it in the DID Resolution
spec... but that's outside of DID Resolver spec. One thing is us
communicating w/ resolver. Queries, paths, fragments to DID
Document itself, not talking about resolver, talking about
DIDs... queries/paths don't make sense, fragments do.
Dmitri Zagidulin: Queries, fragments, paths could pass through
resolver, through resolved DID, to resolved endpoint.
Drummond Reed: +1. Very nicely stated by Dmitri.
Dmitri Zagidulin: I understand JoeAndrieu would like to unify
all of those things into one ABNF, I would argue in the other
direction, 3 ABNF rules, two of them in the DID Document, one
elsewhere (resolver)
Drummond Reed: I am totally fine with separating the ABNF into
three parts as Dmitri suggests.
Markus Sabadello: +1 To what Dmitri said about the meaning of
path,query,fragment to 1. the resolution process, and 2. to
resolved endpoints.
Dave Longley: +1
Drummond Reed: +1 To what ADmitri said
Drummond Reed: To establish lifecycle, those three stages,
ironically hearing things on this call that take more time to
explain at Rebooting... what Joe has been calling a DID and
meaning by DID is what we call a URL. URIs come in many schemes,
HTTP URI, mailto: URI, those are all referred to as URLs.
Drummond Reed: So you put a DID URL in your blog... a DID by
itself is a URL
Drummond Reed: When it's a DID plus anything else it's a DID URL
Drummond Reed: Looking forward to spending time in on DIDs in
Barcelona.
Dmitri Zagidulin: To manu: I think I can address that
Drummond Reed: @Manu—I think to accommodate that (having paths
point inside the DID document), we'd need to establish syntax to
support it.
Dmitri Zagidulin: Paths could be used as JSON-pointer into
document itself - one of the things that could keep the clean
separation, and I expect IPLD, mentions syntax to specify a
syntax as a part of the hash fragment.
Drummond Reed: +1 To putting the path in the DID fragment
Drummond Reed: If it points into the DID document
Jonathan Holt: We are working on more robust querying in IPLD,
but for now it is limited to "/"
Moses Ma: The level of acronyms has gone way up, we need to be
careful when communicating w/ the public. Use common language.
Moses Ma: Maybe use "context free grammar using ABNF" when
writing for the public, we're using a lot more jargon these days
Moses Ma: Bye
Dave Longley: Thanks for scribing, manu and rhiaro!
Received on Saturday, 16 March 2019 03:13:23 UTC