The W3C Credentials Community Group

Verifiable Claims and Digital Verification

Go Back

Credentials CG Telecon

Minutes for 2019-01-29

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:
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: [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:
... 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!