The W3C Credentials Community Group

Verifiable Claims and Digital Verification

Go Back

Credentials CG Telecon

Minutes for 2019-01-29

Agenda
https://lists.w3.org/Archives/Public/public-credentials/2019Jan/0103.html
Topics
  1. Introductions and Re-introductions
  2. Announcements and Reminders
  3. Action Items
  4. DID Pull Requests
Organizer
Christopher Allen, Joe Andrieu, Kim Hamilton Duffy
Scribe
Adrian Gropper
Present
Michael Herman, Dmitri Zagidulin, Lucas Parker, Vaughan Emery, Manu Sporny, Kim Hamilton Duffy, Moses Ma, Joe Andrieu, Ted Thibodeau, Brent Zundel, Mike Lodder, Lionel Wolberger, Brent Shambaugh, Adrian Gropper, Markus Sabadello, Jeff Orgel, Margo Johnson, Jonathan Holt, Justin Richer, Daniel Buchner, Joe Kaplan, Ken Ebert, Dan Burnett, Samantha Mathews Chase, Amy Guy, Heather Vescent, Benjamin Young
Audio Log
Brent Shambaugh: Voip
Adrian Gropper is scribing.

Topic: Introductions and Re-introductions

Introductions... Margo products for Transmute Identity tool for enterprises - self sovereign identiy
Moses Ma: Justin, what SIP app are you using?
Justin is new - Richer - standards IETF, Kantara, eye on this pace for years - involved with new client

Topic: Announcements and Reminders

Next RWoT - Early bird discount ends on Thursday!!!
Daniel Buchner: Says the line is overloaded
Joe Kaplan: VC F2F right after RWoT in Barcelona

Topic: Action Items

Kim Hamilton Duffy: Action items: New action items: multihash hashlink multibase + did resolution and functional identity
Kim Hamilton Duffy: Making sure everything has the required files - baseline cleanup
... if you see things in "need spec text" state, please volunteer - let chairs know - hoping to get htese converged within next month
Joe Andrieu: For two proposed work items from last week - this is your last chance to oppose them
... hearing nothing, they are now formally approved as work items

Topic: DID Pull Requests

... rest of call about pull requests - great work by Amy Guy
... now down to 4 in chronological order
... lots of conversation, not much since April 1, 2018 - summary?
Amy Guy: As soon as there's consensus will rebase
Manu Sporny: Proposal: the only opposition was from Drummond, having a DID method that did not have update, delete BUT may want to create one-time DID
... and it's not a requirement to support update and deactivate but could put editorial text saying it's not recommended but ok
Joe Andrieu: Chris expressed opinion that he's more in Drummon's camp to require these -
... my opinion do we want DIDs to be a universal plugin for a broad range of identifiers. If it's reasonable for USPS to create
... a centralized DID methjod, then it's a bigger issue
Markus Sabadello: It could make sense to support DIDs that don't support update and delete - it's also interesting from a resolution point of veiw
... also good example of DID that don't depend on blockchains - probably a good thing
Daniel Buchner: How do folks define delete?
... also agree probably a bigger problem of DIDs that are not decentralized, with certificates, etc...
Daniel Buchner: How do we define Delete? Need to define what a DID can't be - what's the line?
Johnny: reading through PR, about IoT devices -
Daniel Buchner: IPFS is an example
Joe Andrieu: Q freeze
Johnny: capabilities issue - a device has a role with an expiration - but can't be updated or deleted
Manu Sporny: Delete is defined - if on ledger it's deactivate - some centralized cases can actually delete - need better word than delete
Daniel Buchner: Makes sense - do a final recovery override and wipe it clean. Thanks!
... example: wipe all authentication keys, or capapbilities expire. W/O jumping into decentralize means: do we want the spec to be
Michael Herman: An email is an example of a non-fungible entity ...and meets the criteria "in every other way" as manu just said.
... used very broadly or not? Is email decentralized? Community intent: does it meet the spec in every way, then let's be inclusive
... focus on inclusivity - there are ways of suggesting best practices w/o being exclusive
Daniel Buchner: ***Daniel wonders if this could be something DIF could define outside of the inclusive specs...hmm...***
Joe Andrieu: We win by establising DIDs more broadly. We're talking about decentralized: you can plug any method
... now to other pull requests - to #16 to address 85
Amy Guy: Some will go into resolver spec and Dmitry hgas opinions
Manu Sporny: Waiting - modifies URI definition of DID and adds DID service - a lot of bulk goes into resolution not core specs -
Dmitri Zagidulin: -1 To merging it
... where a DID resolver maps to different URL is out of scope - don't know what the actual URI looks like
Dmitrz: Like Manu and Amy needs more discussion and consensus from the group
Kim Hamilton Duffy: Re PR #55, I see the argument of -- what value are they if they're centralized? how to we make this aspect more readily apparent to users? I also think we should be inclusive at the CCG/DID spec level, but am interested in the best practices/user guidance discussion. To Daniel's thought above, I do think DIF would be a good place to kick that off
Joe Andrieu: Unless changes from recent PR, seems odd that top level of ABNF is a top level, it's a little wacky
Michael Herman: Much of this will be clarified once we get to #159
Dimtrz: ABNF already includes provisions for the service endpoint
Jonathan Holt: What is ABNF?
... more discussion is needed
Jonathan Holt: Augmented Bachus - Nauer Form [scribe assist by Dmitri Zagidulin]
Dmitri Zagidulin: That's the weird formula type thing that defines DID identifier structure
Joe Andrieu: Seems to me the top level shoud be the whole DID
Augmneted Bachus-Naur Form
Manu Sporny: It's a way of writing parsable languages.
... we still need more discussion on that - how might we move this forward?
Manu Sporny: The folks need to get together - we're clearly not on the samer page - dmitrz will take the lead
Dimitrz: in the ABNF the query part seems to be talking about the service endpoint - will take lead on this -
Markus Sabadello: This is also related to the ABNF: https://github.com/w3c-ccg/did-spec/issues/90
Manu Sporny: Make a concrete proposal please,
... we may be ready for a proposal before discussion
.... not a simple discussion -
Joe Andrieu: Maybe make a new PR
Dan Burnett: ABNF is not correct - need to define a schem and not redefine a URI structire - important is the definition
Ken Ebert: Are you looking to replace everthing or correct?
Dmitrz: not sure
Manu Sporny: Will not massively change what a DID lookslike - this is nitpicky spec stuff
JoeAndrieu PR #110
Manu Sporny: We close the PR because we think the mod needed is the way we thionk about IPFS URL
Jonathan Holt: https://github.com/w3c-ccg/did-spec/pull/110#issue-224162685 [scribe assist by Manu Sporny]
... issue is how can we point to something on IPFS that can't change - and the oly thing neccessary for IPFS to publish a URL scheme
... problem solved for linking the keys, hashlink can solve this, no changes needed to specification, - close PR, then johnny can explain
Jonathan Holt: Suggested having / - on IPLD not IPFS - / on a path in IETF - culmination of multihash - suggestion for how to link to content addressable payloads
... not subject to spoofing attacks --- also how we index - uses serialized JSON - ? not determinisitc for serialization to CBOR
... to closing the PR, it's still valid - just reserving the /
Manu Sporny: Can't do that - would need to modify the standard - you have to conform to URI spec - can't change their mind
Benjamin Young: It's not http--it's URIs
Johnnycrunch: this is just the key to an object
Manu Sporny: The way you suggest will not fly at IETF - need IPLD link instead
Manu Sporny: Ipld:zdpuAmoZixxJjvosviGeYcqduzDhSwGV2bL6ZTTXo1hbEJHfq
... in cotext
Manu Sporny: "@Context" : ["ipld:zdpuAmoZixxJjvosviGeYcqduzDhSwGV2bL6ZTTXo1hbEJHfq"]
... that would work with JSON-LD and IETf very simply
Johnnycrunch: I think they will be open to that if it works - as long as the entire content is crypto validated w/o a central point of failure
Manu Sporny: I feel like we have this problem covered - just need IPLD URI scheme
Johnnycrunch: what about indexing of arrays?
Joe Andrieu: Q freeze
Manu Sporny: LD proofs tries not do depend on CBOR - really scary
... we know LD has math proofs working for 6 years - not a light lift to change -
Manu Sporny: We know LD has math proofs working for 6 years - not a light lift to change
Joe Andrieu: Propose next steps
Johnnycrunch: oullined concerns in last paper for RWoT - indexing array makes it so much easier
Joe Andrieu: Manu to take next steps -
Michael Herman: Relevant PR #159 comment thread: https://github.com/w3c-ccg/did-spec/pull/159#discussion_r251057016
... updates to URIs..
Amy Guy: There's more clarification - will make a new PR in the next couple of weeks
Dmitri Zagidulin: Suggest we remove this ?
Markus Sabadello: DIDs need clear relationship: DIDs are URIs that combine the benefots of URI and URN shifting language
Mwherman: need to separate the specs into identifier and protocol parts
Dan Burnett: To be clear, URI != URL. Both URLs and URNs are URIs
Joe Andrieu: Top level ABNF lists all the valid URLs - DIDs are not URLs technically -
Dan Burnett: Yes, I am referring to IETF specs
Manu Sporny: There's some disageement - many different definitions over the years - we cae that a DID can derive a document in some way
... there's academic nitpicking - let's focus on splitting the spec
Joe Andrieu: +1 For restructuring
... list of sections - general buy-in for restructuring - Amy accepted to do PR -
Dmitri Zagidulin: +1
Joe Andrieu: Will let this open pending Amy's PR
Moses Ma: Bye everyone!