- From: Steven Rowat <steven_rowat@sunshine.net>
- Date: Tue, 12 Sep 2017 10:31:34 -0700
- To: public-credentials@w3.org, dlongley@digitalbazaar.com
On 2017-09-12 7:22 AM, msporny@digitalbazaar.com wrote: > Dave Longley: Quick update on credential handler API - it's > coming along - polyfill implementation coming on nicely. Demo > seems to be working on Edge, Firefox, Chrome, etc. It probably > doens't work in Safari - looking for feedback - link to > Credential Handler API repo is here: > Dave Longley: https://github.com/w3c-ccg/credential-handler-api Feedback on Safari (works for me): Using that link, I tested the demo install in my two browsers (FF and Safari): In each: --I chose to make "Personal"; passport came up automatically; installed successfully. --I viewed the JSON code afterwards. OK. Firefox 49.0.2 and Safari 10.0.1 MacOS 10.11.6 Steven > Dave Longley: Looking for feedback on shape of API > Kim Hamilton Duffy: The Chairs will talk about TPAC. > > Topic: ActivityPub and Mastadon > > Chris Webber: https://www.w3.org/TR/activitypub/#Overview > Chris Webber: ActivityPub is a standard that W3C has been > working on for a while - SocialWG is working on it - federated > social networking system. I fyou want to build alternative to > YouTube, Flickr, Twitter, etc., you can use these APIs to build > stuff out - it includes a client/server protocol to build mobile > and desktop applications to talk to server. > Chris Webber: For this group, the server-to-server model is more > interesting. It uses a Linked Data model - it's passing around > JSON-LD using ActivityStreams as the vocabulary for the system. > It's been building off of other systems doing stuff in this space > - oStatus, pubsubhubbub, etc. It's a new protocol - it's > currently at Candidate Rec at W3C. > Chris Webber: https://joinmastodon.org/ > Chris Webber: What's exciting at the moment is that Mastadon is > rolling this out as their main federation protocol. > Chris Webber: https://octodon.social/@webber > Chris Webber: https://mastodon.social/@gargron > Chris Webber: What's neat about Mastadon is that you can see > that both of us have been speaking to each other, even though > we're on completely different servers. What's exciting about them > is... > Chris Webber: > https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/topics-and-advance-readings/activitypub-decentralized-distributed.md > Chris Webber: Mastadon has nearly one million registered users - > they are using Linked Data, JSON-LD, etc. It ties in > ideologically with this group, more decentralized alignment... > Chris Webber: I wrote a paper for Rebooting Web of Trust, in > that paper I go through a few different ways how we can integrate > the work this group is doing and what that group is doing. At > present, ActivityPub isn't very self-sovereign... it's hard to > move to new nodes... > Chris Webber: ActivityPub doesn't specify why you should use > Linked Data Signatures, but there is a good reason to adopt, so > in the paper I describe how ActivityPub and this group align. > Adding public keys and linked data signatures to ensure messages > that pass through network are from who they say they are. > Chris Webber: ActivityPub does still rely on DNS and SSL certs, > so there is still a core bit of centralization there - but it may > be exciting with the work on DIDs, if we could open up those > possibilities to more decentralized mechanisms. > Chris Webber: It would enable users to be more self-sovereign > and move between different instances - we could transition from a > federated model to a more decentralized, more peer-to-peer model. > If public keys are on every actors profile, you're building a web > of trust into the system w/o users realizing it - follow confirm > connections, could be building a loose web of trust. > Chris Webber: I think that's exciting. > Chris Webber: The very day after writing the paper, Eugene wrote > a PR for Linked Data Signatures support - which is great. > Christopher Allen: More specific to the Mastadon community, what > would it take to get them to participate in RWoT? > Christopher Allen: With the goal of moving toward a DPKI - where > is the low hanging fruit? Is it JSON-LD, is it Verifiable Claims? > Is it Bitcoin, Ethereum? > Chris Webber: One thing I've noticed with Mastadon is that it's > very practical. The move from oStatus to a more Linked Data > system using JSON-LD was for a practical purpose... they wanted > to do private messages. The adoption of HTTP SIgnatures and > Linked data signatures was for practical purposes (message > forwarding with integrity) > Chris Webber: I posted this paper to the Mastadon network - > folks said they're interested, can get folks to add to RWoT > Chris Webber: One of the pain points is moving to different > providers. Right now, you have to destroy history to move... but > we could potentially help people move more easily with use of > more decentralized identifiers. > Kim Hamilton Duffy: In terms of decentralized identifiers - are > there any approaches that you've been leaning toward already? > What is the lowest hanging fruit DID providers? > Chris Webber: There are some people that are aware of DIDs... > but people seem to want to avoid too much computational burn. > That is a lot of computation burn in Bitcoin... I've talked w/ > Manu about more fit-for-purpose solutions, where that concern > isn't as strong, maybe build DIDs on top of DHTs (even though I > know some aren't excited about that route). > Chris Webber: We are going to have to prototype and build those > types of systems before we can say for sure. If we end up having > Mastadon adopting DIDs, we'd have a lot of smaller nodes > generating identifiers. We'd have to assume that smaller nodes > can participate in the system - where lots of identifiers > wouldn't bog down the system too badly. That's the gut feeling > I've gotten from bringing these spaces together. > Christopher Allen: To comment on the computational load - that > load is only on creation of identity and identifiers - validating > is very quick. The first time they're creating an identity, there > may be a delay - a guardian relationship may be with first node, > but you can move to self-sovereign when you move the first time. > Christopher Allen: More specific to some short term goals, if > there are some people that are influential - could be persuaded > to check out RWoT, I'd be glad to send them a personal invite to > get them invovled. Just need to know who those people are. > Chris Webber: To be clear, I wasn't trying to downplay Bitcoin, > just letting folks know the feedback I've gotten back. > Christopher Allen: With many of these systems, you can't have > instant gratification, can't login instantly, etc. We may not > want 1 million DIDs, only 200K need to be decentralized - so it > may be a scaling thing - you only need a DID when you need to go > completely self-sovereign or need to transfer. > Nathan George: DIDs make it possible to isolate your identity, > so separation of work life and political life. Can context of > identity be changed based on DIDs? Are you interested in > collaboration there? > Chris Webber: I think you're talking about people being able to > have multiple identities - is that correct? > Nathan George: Multiple identities is one way to think about it, > private conversations w/ some groups is another potential. > Current social networks don't give you much choice between fully > private or fully public. > Chris Webber: One of the things that Diaspora innovated on was > "social groups" - Google+ adopted that with Circles... don't know > if that had as much success as folks though... but the way > ActivityPub addresses it is - email style addressing - you can > to, cc, bcc to send messages - give an array of participants, but > you can also give a collection as a recipient. So you can have > groups that you or someone else curate. > Chris Webber: You can have a "just friends" collection > Chris Webber: When you submit a post to your followers, every > user has a followers collection which is an activity streams > collection - so, one way you can tie in DIDs is to make one of > those collections controlled by a DID. There are two different > ways you can look at this... > Chris Webber: You can have DIDs for each aspect of your life, or > you can have DIDs in each collection of actors. > Nathan George: Yes, great intro, thank you. > Chris Webber: https://www.w3.org/TR/activitypub/#Overview > Manu Sporny: Thanks you, Chris. We know of and are big fans of > the socialWG work. From a corp standpoint, we look at DIDs and > the social Web protocols as the foundational layer for a number > of interesting products in the future. Products where people own > their data and identity. [scribe assist by Dave Longley] > Manu Sporny: They are freely able to exchange in legal economic > activity. A lot of the work with the SocialWG helps with > messaging with machine-to-machine and person-to-person. DIDs make > the data more portable and people know about the Web Payments > work going on. These technologies work well together and we > expect them to converge. [scribe assist by Dave Longley] > Manu Sporny: Chris mentioned Mastodon being one potential > adopter of this tech, our company is already building the social > messaging stuff into our core platform. Dave can talk more about > that if desired. It's not theoretical, it's practical, strong for > profit reasons for implementing these decentralized techs. > [scribe assist by Dave Longley] > Kim Hamilton Duffy: Great, thanks for the overview > > Topic: DID Specification > > Kim Hamilton Duffy: We are tracking a lot of issues now for the > DID spec - Christopher, do you want to walk through Entity > Profile discussion? > Christopher Allen: In the spec, there is an implied concept of > entity information that is a composite of all of the Linked Data > and many signatures that all combine into a large JSON-LD object > that is an individuals representation of what they know about an > entity. > Christopher Allen: This has been implied by the spec, but few > implementations demonstrate this in a way that make people > realize that there is a structure here. Also, how do you keep all > of this in memory when you have many different types of > signatures signed by other entities. There can be many things > signed in parts. > Christopher Allen: How can we being to make this more prominent > - you have it in memory, not in Javascript... how do you look at > this entity and get people to understand one person's entity may > be different from another person's identity? Because of different > disclosures. > Christopher Allen: You may not have a complete description of > the entity. > Christopher Allen: How do we start talking about this next level > higher object - summary of a DID, DDO, Verifiable Claims > associated with those objects... and DIDs/DDOs about those > claims. > Kim Hamilton Duffy: As I moved BTCR more toward what was > outlined in Veres One... in this DID spec, what is the role of > whether it is addressing the Verifiable Claims ecosystem? > Kim Hamilton Duffy: > https://github.com/w3c-ccg/didm-veres-one/issues/1 > Kim Hamilton Duffy: In the previous thread, there is a > discussion about Minimum Viable DID spec, I had some questions > about DID spec V1 is meant to just cover authenticating as a DID > and updating the DDO, or do we want to walk through some broader > verifiable claims scenarios > Kim Hamilton Duffy: It seems like we want to talk about broader > interaction of DIDs in that ecosystem. Just comment/question. > Manu Sporny: I'll attempt to outline the current thinking. It's > really easy to get wrapped around the axle when talking big > picture, especially when talking the technical implementation of > the big picture. [scribe assist by Dave Longley] > Kim Hamilton Duffy: Ach manu > Lionel Wolberger: Add me to q pls? > Manu Sporny: DID spec should do minimum viable [scribe assist by > Kim Hamilton Duffy] > Kim Hamilton Duffy: ...Auth as DID, update DDO > Manu Sporny: What we've found in our org, to get clarity, is to > break the problem down into bite size chunks. The chunks we have > right now are basically: the DID spec, which at least from our > standpoint should do the minimal viable thing. How do you > authenticate as a DID and how do you update the DDO. [scribe > assist by Dave Longley] > Manu Sporny: Taking a first pass at that. In parallel in the VC > work we are talking about making assertions and composing them > together and so on. That work should be independent of the > identifier used. However, when you put the DID stuff together > with the VC stuff you get additional really interesting > properties. [scribe assist by Dave Longley] > Manu Sporny: Like fully portable claims, moving from one wallet > to another. Guardianship over identities, etc. The ability to > compose all these decentralized things together. Christopher's > questions revolve around what the ecosystem looks like when all > the pieces come together. [scribe assist by Dave Longley] > Manu Sporny: And I think he's saying that we should think about > how all these things fit together in the ecosystem we want to > create. The concern is that, until we've really created a solid > foundation for these other specs we can get wrapped up having the > higher level discussion for quite a while. [scribe assist by Dave > Longley] > Manu Sporny: This isn't a proposal that one way is better than > the other, I think we'll have to iterate and bounce back and > forth between the two. [scribe assist by Dave Longley] > Manu Sporny: I think in next 6-9 months we'll be doing > iterations on DID and VC specs and then we see if it works. If it > doesn't work we'll use that info to feed it back in and address > the higher level problems. All that said, we've been doing that > for 4 years. We feel that the general architecture we have now is > valid. And that's why we're trying to nail things down a bit > more. [scribe assist by Dave Longley] > Manu Sporny: So we can do implementations in code across > multiple ledgers and validate it working in production. [scribe > assist by Dave Longley] > Manu Sporny: Digital Bazaar's thinking is to nail these things > down for testing in pilots or in production to make sure use > cases are met. [scribe assist by Dave Longley] > Lionel Wolberger: That was a good lead in to what I wanted to > ask - to achieve interop, the standards will have to guide people > with how to format identifiers. > Lionel Wolberger: Can we point to a standard for location? GPS? > How do we point to standards for expressing that? > Lionel Wolberger: Have we figured out all of the data > serialization issues? > Dave Longley: IMO, URI is spec for the "identifier" ... more > specific data can be a vocabulary discussion > Christopher Allen: Yes, JSON-LD is built to deal w/ > serialization and canonicalization - we do have ways to do that. > Christopher Allen: How do you have a unique identifier? > Legitimately claim ownership on - uniqueness - self-sovereign, > etc. Right to update. Identifier that you control. > Christopher Allen: That is mostly a DID - it can point to DDO, > which can contain additional information about an identifier. > Self-sovereign verifiable claim - I call myself ChristopherA - > unique to me as a root... I call myself christopherA - who I call > kimhd is Kim. If people want to put in Verifiable Claims from > different authorities that have more "realness", they're welcome > to - participation only thing - prove that you're at a location, > various standards to prove how to do that. I think we've met all > of your base requirements, Lionel. > Christopher Allen: In the DID v1.0 draft that was posted, we > predefined proofs to update, proofs to control, we had some > language there - but were arbitrarily saying "these categories", > in the new DDO thing, we're doing more capabilities based... but > will have world expert on capabilities... here are what those > proofs can do, etc. We're discussing how to do that right now. > Lionel Wolberger: Linked data enables you to create, share, > reuse vocabularies at Web scale -- they define the semantics for > whatever it is you want to express ... that includes "location" > or whatever else, there are various linked data vocabs people are > or have created, for example schema.org [scribe assist by Dave > Longley] > Christopher Allen: Thing I'm wondering - last rev of this, we > still don't have an issuer version of this... > Dave Longley: But regarding identifiers specifically, all we need > is "URI" ... and a DID is a URI. > Lionel Wolberger: Thanks, I followed what you said - a claim > that you're Christopher - when do we say that's Unicode. Do we > have definitions for how name/location are represented? > Christopher Allen: There are representations - schema.org - can > be unicode, that's relatively solid. > Christopher Allen: Internationalization is covered, variety of > signature formats - we're adding more to them, but there is a > whole discussion around more kinds of signature formats than we > do right now, not a problem, working on it. > Christopher Allen: When you come to WoT vs. "Real Name", that's > a credential - that's naturally centralized... I claim I'm > ChristopherA - and you accept that or not... or you accept DMV. > Dave Longley: https://www.w3.org/TR/json-ld/ <--spec for > expressing linked data as JSON-LD > Christopher Allen: That is a claim, it's doable with our > system... > Christopher Allen: I want to understand why Longley and Manu > removed issuer key... > Kim Hamilton Duffy: We have a hard stop in a few minutes, we > have a full DID conversation next week. > Ryan Grant: I put a link to Veres One DID Method spec - I think > the names "writeAuthorization" and "authenticatoinCredential" are > great... had a bit of discussion w/ Manu about naming ... > Kim Hamilton Duffy: Have to go. bye > Mike Lodder: +1 > Ryan Grant: The good thing that I see is to generealize > guardianship, the bad thing is mixing what goes into a DDO and > trying to turn that into a Verifiable Claims database... are we > talking about putting a Verifiable Claim into a DDO? That doesn't > seem like the purpose of the DDO. > Christopher Allen: You have to have some kind of pointer at a > minimum > Ryan Grant: In the language of the DID spec, that is services... > Dave Longley: The data model (if you're using JSON-LD/RDF) > supports doing that, but ledgers do not *have* to support it. > Manu Sporny: We're going to have to close out the conversation, > this is the core part of the discussion that the group needs to > have and to come to grips with. The Veres One issue that was > raised identified what we believe to be a logical conflation in > the DID spec that everyone has been making (including us). The > feedback from BTCR made it even more clear that we need to shift > things around. [scribe assist by Dave Longley] > Manu Sporny: It's not just a naming thing, it's about moving to > a more capabilities based model, separating concerns so we don't > tightly bind things that we need to. Christopher, there is no > "issuer thing" because we haven't focused on it, doesn't mean it > wont' be there in the future. We tried to focus and synthesize > current feedback into the core issue people are having. [scribe > assist by Dave Longley] > Manu Sporny: Wanted to focus on getting the foundation right so > the rest of us can build on top of it. There's a certain order > that we think we can discuss these things so the conversation > doesn't go off into the weeds where lower level decisions impact > higher level. Where we all want to be at the end is to cover all > the use cases. [scribe assist by Dave Longley] > Manu Sporny: We think we've boiled this down to its essence but > we need to discuss with the community -- next week's call. > [scribe assist by Dave Longley] > Ryan Grant: I've read the links that I've been able to find and > I'm unable to understand the logic there and I should be able to > see a concrete example. [scribe assist by Dave Longley] > Ryan Grant: Haven't been able to see it. [scribe assist by Dave > Longley] > Manu Sporny: Confused deputy problem, will bring to the > conversation next week. [scribe assist by Dave Longley] > Ryan Grant: I saw an urge to generalize guardianship but I was > unable to find other issues. [scribe assist by Dave Longley] > Manu Sporny: Not necessarily -- I'll try to put that in the > issue before next week. [scribe assist by Dave Longley] > Ryan Grant: Thanks. [scribe assist by Dave Longley] > Christopher Allen: For the purpose of being able to issue Web of > Trust VCs it doesn't meet my requirements for October. [scribe > assist by Dave Longley] > Manu Sporny: I think the solution to your problem is to have an > issuer credential in your DDO. The problem we had before is that > we were using a single key to do multiple different things. Need > to very tightly couple key purpose ... number of issues bundled > together. [scribe assist by Dave Longley] > Manu Sporny: I'll try to explain that a bit more. [scribe assist > by Dave Longley] > Ryan Grant: Definitely need a clearer read on that. [scribe > assist by Dave Longley] > Ryan Grant: My reading of guardianship was clear. That the > guardian had the capability to update. The error did not exist in > other cases. [scribe assist by Dave Longley] > Manu Sporny: I will type something out. [scribe assist by Dave > Longley] > Manu Sporny: Christopher, your concern is easy to address and > it's an issuerCredential ... it's not in there right now but it's > an easier thing to do. [scribe assist by Dave Longley] > Christopher Allen: Thanks. [scribe assist by Dave Longley] > Christopher Allen: Kim had to logout, to recap we'll have a > discussion next week we'll have ethereum and blockstack > (hopefully), BTCR, ... talking about what requirements we're > missing in the latest discussion on DIDs. [scribe assist by Dave > Longley] > Ryan Grant: My reading of guardianship was that its permissions > were clear > Christopher Allen: In following weeks, we need to make sure > bootstrapping and rebooting web of trust work well at RWoT, so > we'll be prepping for it until then. > > > > >
Received on Tuesday, 12 September 2017 17:31:41 UTC