[MINUTES] W3C Credentials CG Call - 2019-03-19 12pm ET

Thanks to Amy Guy and Dave Longley for scribing this week! The minutes
for this week's Credentials CG telecon are now available:

https://w3c-ccg.github.io/meetings/2019-03-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-03-19

Agenda:
  https://lists.w3.org/Archives/Public/public-credentials/2019Mar/0032.html
Topics:
  1. intros
  2. announcements and reminders
  3. Action items
  4. https DID method spec, and more
Organizer:
  Kim Hamilton Duffy and Christopher Allen and Joe Andrieu
Scribe:
  Amy Guy and Dave Longley
Present:
  Brent Zundel, Joe Andrieu, Amy Guy, Andrew Hughes, Michael 
  Herman, Jeff Orgel, Yancy Ribbens, Moses Ma, Dave Longley, Adrian 
  Gropper, Dmitri Zagidulin, Samantha Mathews Chase, Christopher 
  Allen, Ted Thibodeau, Ken Ebert, Kim Hamilton Duffy, Jonathan 
  Holt, Markus Sabadello, Kaliya Young, Drummond Reed
Audio:
  https://w3c-ccg.github.io/meetings/2019-03-19/audio.ogg

I'm here in the text but not on audio
Christopher Allen: @Manu I’m unable to dial in again. “the 
  subscriber is not available. Error wa000256”
Christopher Allen: @Manu third week in a row from my T-Mobile 
  cell
Amy Guy: I can scribe
Amy Guy is scribing.

Topic: intros

Joe Andrieu:  Anyone here who is new?
Joe Andrieu:  Who is bengo?
  ... chrisboscolo, have you introduced yourself?
Chrisboscolo: I have, but I can reintroduce myself. I've been 
  aprticipating for a little over a year. Founded lifeID, building 
  an open source version of a ssi platform
Joe Andrieu:  Last chance for anyone new?
  ... don't be shy

Topic: announcements and reminders

Joe Andrieu:  First, if yo haven't seen the emails, the folks who 
  have been focussed on the DID spec and DID resolution have more 
  calls on thursdays, one on the DID spec itself which is 1-2pm PDT
  ... which is currently 20 UTC, that's not gonna be true in a 
  week, we'll update this
  ... And then the DID resolutions spec call will follow on that, 
  every week. The zoom is in the agenda. Please join if you want to
  ... The other announcements: the KNOW conference is coming up
Joe Andrieu: https://www.gbaglobal.org/event/know-las-vegas-2019/
  ... We look forward to reports if any of you are attending
  ... And IIW is april 30 - may 2, a lot of us will be there
Joe Andrieu: https://www.internetidentityworkshop.com
  ... Any other announcements?
Joe Andrieu: 
  https://github.com/w3c-ccg/community/issues?q=is%3Aopen+is%3Aissue+label%3A%22action%3A+review+next%22

Topic: Action items

Joe Andrieu:  Thanks kimhd for processing this work in the 
  background
  ... These are the items the chairs pulled out on friday
Kim Hamilton Duffy:  Number 59, DID methods in the registry 
  without specs
Kim Hamilton Duffy: 
  https://github.com/w3c-ccg/community/issues/59
Kim Hamilton Duffy:  When that started we had 4 DID methods 
  without an associated spec
  ... one of them had been addressed adn I think it's jolocoms
  ... That one is good
  ... We still have missing specs for domino'd(?), uPort and 
  consent(?)
  ... I think dominode was added without a spec and I don't have 
  a contact
  ... uPort and consent(?) were probably just overlooked. We do 
  have individual issues tracking those
  ... maybe drummond and manu can track those down
Kim Hamilton Duffy: W3c-ccg/did-method-registry#29 
  w3c-ccg/did-method-registry#31 w3c-ccg/did-method-registry#32
Kaliya Young: I am in touch with Dominode folks and will ask them 
  to be in touch
Michael Herman: PSA (unrelated to the current topic of 
  conversation): I've launched the INDY ARM (Architecture Reference 
  Model) Interactive Explorer yesterday. Checkout 
  https://github.com/mwherman2000/indy-arm/blob/master/README.md#indy-arm-interactive-explorer
  ... I think what we're going to do here is pull in the editors 
  of that DID method registry to make sure of the process but I 
  think that we're gonna have to start clamping down at some point 
  and saying 1) we have to enforce for a PR you have to link to a 
  spec and that spec has to have certain minimal properties. I've 
  noticed drummond is enforcing that recently. But for these ones 
  that got in there without a link we have to figure out what to do 
  with
Them
  ... There' sprobably a spec somewhere that has to be pointed to
Joe Andrieu:  Process-wise, I'm trying to take a lesson from 
  IANA's handling of when DNS records go bad, whichi s to be very 
  slow about pulling things out becuase of failure to communicate
  ... It was mentioned in one of our calls we should just delete 
  those.. but these people may not know they're on the verge of 
  being deleted. I don't want to take them out until we've gone 
  through some process and tried to reach them and given them an 
  opportunity to participate
Michael Herman: Also launched the SOVRIN ARM Interactive 
  Explorer: 
  https://github.com/mwherman2000/sovrin-arm/blob/master/README.md#current-scope
  ... If they're old and out of date we will remove them. Want to 
  give them some time
  ... Thanks Kaliya for offering to reach out to the dominode 
  folks
  ... I'd love to see the specs from these folks. We don't want 
  to kick people out, just make sure the methods that are securing 
  names are in fact viable at some level
  ... Right now that means having a written spec
  ... The next issue is the DID exlpainer for the TAG and 
  integration into the DID Primer
Kim Hamilton Duffy: 
  https://github.com/w3c-ccg/community/issues/38
  ... This was assigned to me and burn, and burn has his hands 
  full with VC today
  ... THere was a question on this. Namely around whether or not 
  the explainer is something we need for the charter?
  ... I think that relates in particular to does the w3c TAG do 
  anything wrt to the charter?
  ... I was hoping manu would be on the call because I think he 
  knows something about that... Anyone else know the process well 
  enough?
Dave Longley:  I would say we definitely want an explainer when 
  the charter goes out, it helps people understand who the 
  technology is going to be used for, what it's trying to do, 
  educate people why they should be voting for the charter
Joe Andrieu:  I agree we need something, but the explainer is a 
  particular structure the TAG asked for. We now have 3 active 
  publications. The explainer, the Primer, and a document drummond 
  started at rebooting. I feel like we have too many documents 
  trying to scratch the itch you just described
  ... To me the issue is that explainer as requested by the TAG, 
  ie something more than what we have in the primer
Drummond Reed:  We wanted to make sure the document we started at 
  Rebooting was not to start any confusion about what is needed for 
  the w3c applicaiton process for the DID charter
  ... whatever is needed there we want to design specifically for 
  the DID charter. We weren't intending that document to be part of 
  the DID charter
Joe Andrieu:  Thanks for that clarification
  ... I'm going to leave this issue as it is. I'd like to check 
  in with someone who understands the TAG's role in chartering
  ... We'll review this again next week
  ... Apparently this needed to be done by mid January..
Kim Hamilton Duffy: 
  https://github.com/w3c-ccg/community/issues/21
  ... Last issue in that set is #21
Kim Hamilton Duffy:  I put myself on the q to disagree with that 
  latest comment. It's the various ethereum ?? 725 is one.. There's 
  some publications like the one uPort has published.. Chris's 
  latest comment is that it shouldn't be closed until there is 
  documentation in one of our repos
  ... My personal opinion is that that's just not really required 
  here
  ... I don't know why we're putting that burden on ourselves
  ... The things that we care about are covered in the DID method 
  registry. If they want things to be.. if they want to reference a 
  DID method there it's appropriate, but we don't have that 
  reuqirement for anything else. Documentation of a different 
  community's efforts are not required
  ... I'll comment saying that
Joe Andrieu:  Thanks kim
  ... Chris?
Markus Sabadello:  At some point there was someone who 
  volunteered to do that research on documentation but I guess that 
  didn't happen
  ... I just know that erc725 proposal is changing quite a bit, 
  there's a new version of that, version 2 or something like that
Kim Hamilton Duffy: Drabiv is assigned this
  ... I also know that jolocom people have some documentation or 
  information that lives in thier FAQ on their website that 
  explains
  ... why they create their own ethereum based DID method
Dave Longley: What i'll say about the explainer and similar docs 
  is that any supplemental material that helps the AC understand 
  *why* they should vote for something is extremely important -- if 
  we want a successful vote, we want to educate the AC as best we 
  can (without giving them reams of material to go through ... and 
  an explainer can help significantly with that) ... so it's less 
  about what is strictly required and more about what we can do to 
  get a successful vote
Dave Longley: To get a WG started.
Joe Andrieu:  I don't know what next steps are for this
Kim Hamilton Duffy:  I just don't think we need it here. It's 
  useful in general for people to have access to, but it's not an 
  action item for the CCG
  ... Maybe chairs can discuss on friday. But I'll ping bohdan to 
  see if he has plans to address it. Otherwise I think we can close 
  it
Joe Andrieu:  I agree
  ... Those were our open issues for this week
Joe Andrieu: 
  https://github.com/w3c-ccg/did-method-registry/pull/25

Topic: https DID method spec, and more

Joe Andrieu:  Please read this
  ... I want the conversation to be more than about the https 
  method spec. Markus proposed tongue-in-cheek the facebook method 
  spec. Ther eis a wider question about do DID methods need to be 
  decentralised at a method level
Markus Sabadello:  The facebook proposal is not a serious 
  proposal, just an attempt to add colour to the discussion when I 
  saw the https method
  ... my opinion is that neither facebook usernames or domain 
  names are decentralized identifiers. Every presentation about 
  zooko's triangle, you here domain names as an example of 
  identifiers that are unique and human readable but not 
  decentralized
  ... I believe that is the essence of what distinguehes user 
  centric identity vs self sovereign identity
  ... Doesn't fulfil strict assumptions of ssi
  ... Also don't satisify the original assumptions of the dpki 
  infrastrcture
  ... which says identifiers don't depend on any central 
  authority or intermediary
  ... The challenge we have here is that with DID documents we're 
  inventing a discovery and document format that describes metadata 
  about identifiers. that could be useful also for identifiers that 
  are not DIDs. That's the challenge here
  ... We're building DIDs but we are also building DID Documents, 
  and DID Docs as a discovery format could be useful for 
  identifiers that are not decentralised, just domain names
Dmitri Zagidulin:  I'd like to provide a counterpoint
  ... I think an https did method could provide a really valuable 
  bridge technology for the various providers. It's a way to 
  include a section of the decentralised identity community, like 
  timbl's solid project and similar ecosystems. It's a way to get 
  them to join the conversation, join the ecosystem. After they've 
  joined we can make an arguement that okay you took this step, 
  here's why a ledger based DID is even better than an https based 
  DID. But to
Deny them entrance on the groudns that they're not decentalised 
  enough is really unhelpful
Kim Hamilton Duffy:  Never used facebook, but I love this method. 
  I liek that markus called it out. For me and a lot of us are 
  trying to present DIDs and their different properties, it's very 
  useful from an educational perspective. To build on what dmitri 
  was saying, it's good for teasing apart.. if you work with a 
  facebook DID method it's easy for people to understnad what that 
  is
  ... One of the points of failure of using facebook as your 
  ledger.. a good way to point out the boundaries and the strengths 
  of other DID methods
Drummond Reed: To pre-scribe what I'm about to say, I feel *very 
  strongly* that the DID spec needs to take a strong stance about 
  the actual decentralization of DIDs. Perhaps even objective tests 
  about the level of decentralization of any DID method.
Joe Andrieu:  Question for markus: I was left wondering what your 
  position was. It seemed like you started out saying if the 
  underlying method isn't itself decentralised then it shouldn't be 
  a DID but then you made a case that the discovery method might 
  make that interesting and therefore allowed?
  ... Two things - we may already be decentralised. Which really 
  gets to.. what does it  mean to be decentralised?
  ... The fact that I can use different DID methods is a form of 
  decentralisation. There is no central authority in charge of what 
  methods are out there. The registry is a lookup, it's not 
  definitive. We don't have that level of decentralisation of DNS
  ... I don't have an opportunity in a domain namem to say I want 
  to use this other root. But with DIDs you can
  ... The ability to vary the method is in fact a form of 
  decentralisation at the platform level
Drummond Reed: I do not, however, believe the DID spec should 
  prohibit DID methods that are based on centralized systems. I 
  just thing we should properly warn about them in the DID spec 
  editorial text.
  ... Even if that's not sufficient, the quesiton is what does 
  decentralisation mean with enough clarity so that we could make a 
  judgement about whether or not a particular method qualifies as a 
  DID method
  ... I don't think there is such a defnition
  ... I haven't heard a compelling one
  ... I don't know how to define it to be rigourous
Drummond Reed:  I love markus' post. We had good discussions at 
  rebooting about 'centralised' DID methods. I believe we should 
  not prohibit because we really can't, DID methods based on 
  centralised registries. But the spec should be very clear about 
  what decentralisation really means and that the level of trust or 
  assurance that you can have in DID methods that rely on 
  centralised registires is different. We shoul dnot mince words 
  about the point of the
Spec being DEcentralized identifiers
  ... But I don't think we should prohibit other ones
  ... It be comes a different question what we should do about 
  methods that are clearly based on centralized registires in the 
  DID method registry
  ... I might consider that we look at categorising or having a 
  separate category section fo that for if we do start to register 
  DID methods based on centralised registiry. We could put them in 
  a separate sectiona nd cearly warn that these methods are not 
  based on decentralized systems
Michael Herman: +1 For the emphasis on *decentralized* 
  identifiers
Jonathan Holt: Did:ipid:jonnycrunch.me
Jonathan Holt: 
  "Dnslink=/ipld/zdpuB1oR3vjYmkDc9ALfY7o6hSt1Hrg2ApXaYAFyiAW5E4NJP"
Jonathan Holt:  In the IPID spec we do support DID syntax, human 
  readable names that resolve. I don't like it, it relies on DNS in 
  the background, in particular the text field being a DNS link
  ... This will resolve and be cached into the DHT
Michael Herman: ...Especially in the spirit of the 
  @OpenForInnovation Principle: 
  https://hyperonomy.com/2019/03/12/internet-protocols-and-standards-not-only-need-to-be-open-but-more-importantly-open-to-innovation/
  ... It's human readable and convenient but opens all sorts of 
  vulnerabilities. But like dmitri says, it's a bridge tech
  ... I demo'd this in barcelona
  ... It was resolving offline. Opens up issues of security, 
  that's why it came up
Markus Sabadello:  Decentralization is hard to define. There are 
  a lot of ways to argue. There's one attempt to define a metric of 
  decentralisation in the dpki paper. And one of the comments on 
  the PR by sandro that says control is often obfuscated and it's 
  not black and white
Kaliya Young: I am quite concerned
  ... But facebook user names just like domain names are with all 
  the background and history we have with user centric identity and 
  ssi I don't think we can consider them decentralised identifiers
Kaliya Young: I think we have to remember about the capture of 
  OpenID abt the big guys
  ... If we add them to the method registry, the http smethod.. I 
  understand the convenience and how it can be a bridge, but it 
  will be a contradiction to what the dpki paper and the DID spec 
  itself says in the abstract
  ... It simply doesn't apply to domain names
Kaliya Young: The original vision was so nice and idealist. But 
  it was coopted by them
  ... The challenge is that we're defining an interesting 
  discovery format, called the DID Document, which can be very 
  useful for metadata about centralised identifiers, but we should 
  not call them DIDs. People who are working with domain names or 
  https URLs, they could use webfinger
  ... But if they want to use DID Docuemnts, because they're 
  cool.. there's also WebID profiles, that's another discovery 
  format, in the solid space
  ... There's a WebID profile in the standard
  ... What people want to do is use DID Documents as a useful and 
  smart new discovery format on identifiers that are not DIDs
  ... Maybe we should rename the format. Maybe not DID Document 
  but instead something else
Joe Andrieu:  I love the contributions that Sovrin and Evernym 
  have brought to DIDs and VCs but there's a legitimate positoin 
  that says permission blockchains have a centralising function
  ... Those who give permission can be subject to action by the 
  state, via subpoena or force
  ... Both of those ideas of what it means to be decentralised 
  are valuable
Drummond Reed: Sovrin is "Decentralization by Design" - to have 
  enough stewards in enough jurisdictions that no government actor 
  could interfere with the network as a whole.
  ... I like what drummond said in terms of we probably shouldn't 
  deny methods that are in some way decentralised, becasue we 
  can't, but that we should advocate for some notion of 
  decentralized identifiers
  ... We just need to come up with that that notion is
Chrisboscolo: instead of trying to frame it was whether it's 
  centralised or decentralised, can we frame it in terms of the 
  seciruty guarantees the creator of the DID has over the DID. With 
  https for exmaple, I can create a DID and lose control over the 
  ability to replace the DID Document
Drummond Reed: For the full set of Sovrin Decentralization by 
  Design principles, see 
  https://docs.google.com/document/d/1WqUOqdTBc3JACIlRviJoWJRcJHTNTNzk9_As9v-jwrY/edit#heading=h.bdrt4wmem38w
  ... There's some guarantee based on the method that the creator 
  of the DID can at least identify if the Document has been 
  tampered with or is different. Can we frame the requirements in 
  terms of the securiyt of the lookups?
Joe Andrieu:  That's a great suggestion
Samantha Mathews Chase:  I was trying to get clear on.. maybe you 
  could give an example of the use cases behind whether you'd want 
  it to resolve to something like your facebook. In terms of 
  something like machine readable terms or consent for .. ?? have 
  expressed interest in DIDs. Would the use case be something like 
  these are my adPreferences or my trackingTerms and that woudl 
  resolve to somewhere that already tracks me, but now has a 
  document that alreayd tracks
Me
  ... Would that be the arguement for using something like that?
Kim Hamilton Duffy: +1 To Chris Boscolo's suggestion. Degree of 
  centralization/decentralization has more of a value judgment 
  attached; whereas creator guarantees (or something along those 
  lines) allows more nuanced, use-case-dependent discussion
Markus Sabadello:  Besides decentralisation, what we also claim 
  for DIDs is persistence. Domain names and usernames are not 
  persistent either. THat's a known problem in the identity space, 
  since the days of OpenID
Joe Andrieu:  To respond to sam, two things
Dmitri Zagidulin: -1 To persistence requirement. since that 
  doesn't address ephemeral / on-the-wire DID methods
Andrew Hughes: +1 To @chrisboscolo - the notion of 
  ‘decentralization’ as a philosophy to resist central authorities 
  makes using it as a technical categorization approache very 
  difficult
Dave Longley: Technical considerations and control guarantees are 
  much better measures for determining the validity of DID methods 
  or categorizing them
  ... Ideally the DID Document should not contain any persionally 
  identifiable information, which to my mind is likely to include 
  preferences of the kind you mentioned
  ... DIDs can be a gateway to look up prefs, but they shouldn't 
  be in the document
Drummond Reed: +1 To Markus' point about persistence. DIDs have 
  *four* core qualities: 1) global uniqueness, 2) persistence, 3) 
  cryptographic verifiability, 4) no centralized registry required.
Dave Longley: Vs value judgments using squishy definitions of 
  "decentralized"
Drummond Reed:  /Some/ DIDs have the persistence quality. not all 
  fo them. [scribe assist by Dmitri Zagidulin]
Drummond Reed: If it doesn't meet those four qualities, it should 
  not be called a DID.
  ... That use case might be out of scope. But I think the use 
  case is simply to say, for example right now, facebook doesn't 
  pvoide a way to attach a public key to my facebook login. So 
  people who trust facebook can bootstrap a key that's associated 
  with me
  ... That only has a security guarantee that fb provided it, so 
  fb could have faked it, but for those who are willing to rely on 
  that guarantee, at least they have a public key on which we can 
  bootstrap other forms of interactions
Samantha Mathews Chase: Thanks joe
  ... that's my attempt at a usecase
Samantha Mathews Chase: Muted
Dmitri Zagidulin:  About the 4 core qualities of DIDs.. only 
  cryptographic verifiablity is a worthwhile one to focus on. 
  Ephemeral DIDs, off ledger, on the wire DIDs, especially Sovrin 
  ones from rebooting don't have the persistence reuqirement
Joe Andrieu:  I do think that's the direction we can go to in 
  terms of talking about qualities.. I'm not sure I like all of 
  them. We don't have consensus. but that moves us into a direction 
  for a definition of what we mean by decentralised. We can say 
  this is what we mean by DIDs
Jonathan Holt: I think Dmtri was referencing the "peer" did 
  method? which is not persistent, which is a valid use case 
  against persistence.
Dmitri Zagidulin: Yes! the peer method
Drummond Reed:  What dmitri said gave me an idea about how we 
  might characterise it. I've been talking about those 4 qualities 
  for q uite a while. Sovrin has test networks. They're not 
  persistent, they can get reset. There are DIDs on them, but those 
  particular DIDs on that particular network do not have that 
  persistence. DIDs on the Sovrin main network, the whole reason 
  for the network, is global uniqueness, persistence, cryptographic 
  verifiability and no
Centralisation. Even to the point that it's a permission network 
  is that it's centralized.. the amount of work that's gone into 
  Decentrlaiztion by Design.. you can always debate it, but there's 
  a lot of work going into that
  ... At least on those 4 dimensions, and maybe there are others, 
  any one DID method could be looked at and say some DID methods 
  don't have persistence, and some use centralized registries.. I'm 
  on the fine line whether we can objectively judge DID methods 
  that way
  ... But to markus's point, I agree with the tension about 
  whether we can call it a DID if it relies on a centralized 
  registry
Joe Andrieu:  I know kaliya had comments in IRC about the 
  whitewashing of openID
Michael Herman: As a bootstrapping tactic, Facebook's Other Names 
  section of the FB profile is a potential place to store a DID but 
  unfortunately special characters are not allowed: 
  https://www.facebook.com/help/112146705538576?helpref=faq_content
Drummond Reed: +1 To Kaliya's point about empowering individuals
Dave Longley is scribing.
Joe Andrieu:  Thanks for that conversation. I'm not sure if the 
  consensus has shifted but there's more clarification on the ideas 
  here.
Markus Sabadello:  I just wanted to say, orthogonal maybe to this 
  discussion, whether or not we want to be able to discover DID 
  documents from domain names/usernames. To be able to discover 
  DIDs from non-DIDs. It could start from any facebook 
  identifier/other and find a DID from that.
Michael Herman: FB doesn't even allow numbers in a Name
Drummond Reed: +1 To Markus' point about enabling discovery of a 
  DID from another non-DID identifier like a URL or domain name
Markus Sabadello:  So you only use the human readable identifier 
  to discover a DID and then you keep working with the DID. There 
  is some work that's been done on that. Discovering a DID from a 
  domain name, etc. ... that's an additional feature, it doesn't 
  answer whether we want to be able to discover DID Documents 
  directly from a non-DID.
Dmitri Zagidulin: Consensus wise, I at very least heard fairly 
  uniform agreement that we /cannot/ forbid an inclusion of a DID 
  method (such as the HTTPS method) into our informal registry
Markus Sabadello: Draft spec for discovering a DID from a domain 
  name: https://datatracker.ietf.org/doc/draft-mayrhofer-did-dns/
Jonathan Holt:  Just going back to the DNS link I shared. It is a 
  cryptographic key pair in DNS and it's a bridge technology. Maybe 
  how we do this with DNSSEC or signing cryptographically the link 
  to the IPLD object... I don't like it but I think it's a bridge 
  tech.
Kaliya Young:  I'm really concerned because of the history of our 
  community developing protocols that are designed to empower end 
  users and individuals then... differences with URLs being the 
  basis of identities but the intentions are similar. Then big 
  companies picked them up and implemented them. So every time we 
  log in with google or facebook via OAuth, but they're 
  centraliseed. I hear the idea that [scribe assist by Amy Guy]
Amy Guy: DID Docs can be used for any endpoint. I don't want to 
  see this get coopted. I want us to actually build the 
  decentralized thing we're talking about
Drummond Reed: +1 To bridging conventional identifiers and 
  infrastructure to DIDs. That's how adoption always happens.
Moses Ma:  I'm working with the Universal? Postal Union and one 
  of the things we're talking about is being able to do is resolve 
  a postal address from a DID. The idea here is that countries are 
  sovereign but subservient to the UN or the rule of law. And 
  humans should be the same way, and the rule of law is what we 
  should be subservient to and we should deal with that in our 
  system instead of complete chaos/anarchy. I'd be happy to talk to 
  anyone offline about that.
Jonathan Holt: I should clarify the cryptographic is a password 
  to access write to the DNS record. NOT ideal, but proves that I 
  own the DNS record.
Amy Guy is scribing.
Joe Andrieu:  Other people can speak to how broadly it's used, 
  but there's a notion of trust on first use. It's a certain level 
  of quality yo ucan give to the underlying crypto identifier, eg. 
  when you ssh into a server you've never been to before you'll get 
  a popup that says hey do you want to save this key forever. 
  You're going to be trusting that key because it's your first use 
  an dyo udon't hav ea better key. That's a particular architecture 
  for a
Certain quality assurance about a particular key. That's all some 
  of these bridge technologies are good for. We'r enot trusting fb, 
  we're using fb as a trust on first use type of level
  ... Anyone else?
  ... We can wrap early. Thanks for the conversation
Michael Herman: DIDs can be added to Facebook as "Life Events"
  ... Some of this can flow into the DID spec conversation, how 
  we might do some of that dance between what we watn to advocate 
  without trying to prvent DID methods that aren't centralised. 
  THere's language in there we can flow into the DID spec about 
  what we advocate ideologically
Drummond Reed: To remind folks about the DID spec and DID 
  Resolution spec calls on Thursday
Michael Herman: ...Which kind of makes sense.
Drummond Reed:  Quick reminder that we will begin regular weekly 
  calls on Thursday, first hour on DID spec, second hour on DID 
  resolution, starting this thursday
  ... We sent an email to the list.
  ... Thank you markus for hosting the zoom room.
Joe Andrieu:  For clarity, that'll probably continue past the DST 
  skew. The set time is in Pacific
  ... When Europe changes to DST in a week or two, the pacific 
  time will stay the same but the meetings will shift an hour
Drummond Reed:  We'll send a reminder to the list the day before
  ... Joe, we keep the notes in a google doc and send the 
  contents to the list? Is that okay or do we need to use irc?
Joe Andrieu:  I think capturing in a google doc in terms of ipr 
  requirements is half way there... if the google doc stays 
  around.. I guess the problem is that you lose attribution
  ... Or if the notes clearly say who says what then we still 
  have it
Kim Hamilton Duffy: Markus is uploading audio too
Drummond Reed:  We've been recording the audio in the DID 
  resolution calls
Joe Andrieu:  That is useful as well. We have an automated 
  pipeline for these calls
Kim Hamilton Duffy:  The other thing about these calls, we can 
  take this offline, we need to talk to manu about it. There's this 
  whole thing where we're recording and I don't know how to get 
  into the schedule to use that pipeline
  ... So for these just do what you can
Drummond Reed:  That's what we've done in the past, just double 
  checking
Joe Andrieu:  On the google doc as long as you're clearly 
  attributing who said what then that will help with ipr questions
Drummond Reed:  Right
  ... It's open to anyone in the CCG
Joe Andrieu:  Adjourned, thanks everyone
Moses Ma: Bye peeps!

Received on Sunday, 24 March 2019 01:01:29 UTC