W3C home > Mailing lists > Public > public-credentials@w3.org > September 2017

[MINUTES] W3C Credentials CG Call - 2017-09-19 12pm ET

From: <msporny@digitalbazaar.com>
Date: Tue, 19 Sep 2017 14:18:40 -0400
Message-Id: <1505845120804.0.25520@zoe>
To: Credentials CG <public-credentials@w3.org>
Thanks to Heather Schlegel for scribing this week! The minutes
for this week's Credentials CG telecon are now available:


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 2017-09-19

  1. Introductions and Reintroductions
  2. Proposed changes to DID Spec Overview
  3. DID Spec Discussion
  Kim Hamilton Duffy and Christopher Allen
  Heather Schlegel
  Heather Schlegel, Drummond Reed, Daniel Buchner, Christopher 
  Allen, Manu Sporny, Dave Longley, Ryan Grant, Kim Hamilton Duffy, 
  Joe Andrieu, Adrian Gropper, Mike Lodder, Christian Lundkvist, 
  Nathan George, Chris Webber, Andrew Hughes, Moses Ma, David I. 
  Lehn, Brent Zundel, Adam Migus, Chris Chapman, Jim Goodell

Heather Schlegel is scribing.

Topic: Introductions and Reintroductions

Heather Schlegel:  Hi, Heather Vescent - I have been lurking on 
  the Verifiable Claims and Interledger lists, other W3C lists as 
  well. [scribe assist by Manu Sporny]
Heather Schlegel:  I thought I'd drop in and see what is going on 
  - I'm a futurist researcher, study digital identity, security, 
  money and transactions, a lot of that kind of stuff. [scribe 
  assist by Manu Sporny]
Drummond Reed: Heathervescent has been part of the IIW community 
  for many years. She also produced a 7 minute film about IIW.
Daniel Buchner:  I'm wondering if there is a lot of discussion 
  related to ActivityPub in this group?
Christopher Allen:  There was a proposal for rebooting web of 
  trust, unable to attend this call. supporting efforts in 
  credentials, but they have their own community group meeting, 
  learning how to incorporate verifiable claims and DID stuff they 
  have in their proposals to ActivityPub
Manu Sporny:  Looking at doing coordination with activity pub. 
  Chris Webber is the best person to contact for this. (Daniel was 
  the previous speaker)
Drummond Reed: What is ActivityPub? Brief description?
Dave Longley: Drummond, here's the spec 
Daniel Buchner:  Ok, well I'm at Microsoft now, but when we were 
  working on social web stuff at Mozilla, we tried this approach 
  and ended up wanting to do something more generalized, which is 
  what we're working on now. So, wanted to engage on the 
  ActivityPub stuff to discuss.
Ryan Grant:  Is digital bazaar DID spec on the agenda today?
Kim Hamilton Duffy:  Yes, it is, Ryan.
Christopher Allen:  Covering DIDs all day
Drummond Reed: I can also give an update on the DID Primer.
Kim Hamilton Duffy:  New name and mission statement discussion.
  ... action item assigned to Manu: follow up with Dan Larimer at 
Manu Sporny:  Still in process, they'll join when their schedule 
  frees up a bit.

Topic: Proposed changes to DID Spec Overview

Kim Hamilton Duffy:  DID review: have a lot of people to talk 
  about the broader impact changes for the spec. Manu will drive 
Kim Hamilton Duffy: Manu's pull request, which attempts to 
  address a number of issues: 
Manu Sporny: The issues are being triaged here: 
Kim Hamilton Duffy: You can preview the proposed changes here: 
Manu Sporny:  Quick update on DID spec.
  ... triaged number of issues around DID: e.g. authentication. 
  Do we talk about digital signature, biometric proofs, discussion 
  around the security model for DID document.
  ... exploring moving to capabilities security model.
  ... express authentication credential public/private biometric 
  ... best way to move forward on all these issues.
Manu Sporny: Proposed update to the DID specification: 
Manu Sporny: There is a complete example here: 
  ... Link is the new proposal... supports all the use cases 
  we've always discussed.
  ... addresses the use cases with simplified concepts.
Dave Longley: Authentication/authorization semantics are more 
  explicit with the new proposal
Manu Sporny:  There are those of us implementing these ideas
  ... have learned from our past experiences and incorporating 
  our learning into it.

Topic: DID Spec Discussion

Ryan Grant:  Do you cover org control, manual re-implementation 
  for ssi contacts. affirming a change for users on different 
  teams.  is it supported?
Manu Sporny:  Yes.
  ... in the new spec it is the authorization field.
Heather Schlegel:  OrControl and AndControl, section 6.5 of the 
  old spec [scribe assist by Ryan Grant]
Manu Sporny:  Future things we submit, proofs on various 
  blockchains (eth, etc)
Ryan Grant:  How do I do that.
Manu Sporny:  Look at Appendix B.
Joe Andrieu:  Would be great to explain the logic.
Manu Sporny:  Will update the spec text.
Manu Sporny:  I need to understand more before approving.  More 
  intermediate text may be required.' [scribe assist by Ryan Grant]
Drummond Reed:  Raising issues not addressed: (didn't catch 
  everything) Suggestion: we look at the architecture first.
  ... decided the tradeoff between arch, then use cases, then 
  update the text.
Manu Sporny: +1, Totally agree w/ Drummond's approach to updating 
  the spec... think its the right approach.
Christopher Allen:  Is there a place that talks about issuer 
Manu Sporny:  Yes. Issue credential capabilities. Self issuring. 
  In Appendix B.
Christopher Allen:  General architecture is good. Mark Miller 
  will be at Rebooting/Boston.
Drummond Reed: Link to the Google doc draft of the DID Primer: 
Drummond Reed: Feedback and input into the DID Primer is welcome 
  from all DID community members.
Adrian Gropper:  One concern. Re: recovery of credentials that 
  are non repudiable.
Christopher Allen:  Not the DID spec that does that.
  ... goes on to describe other options.
Drummond Reed: +1 To nage's concern to not entangle policy beyond 
  simple universal semantics
Mike Lodder: +1 Nage
Drummond Reed: Capabilities are good but the more system-specific 
  they become, the more complex the whole space becomes
Manu Sporny:  Responding to Drummond. It's not in the spec yet.
  ... DB thinks we do need that. Concerned/working through w/ 
  unintended consequences.
Daniel Buchner:  Microsoft might be using DIDs in production 
  sooner than later.
Drummond Reed: I'm coming at this as much from a key management 
  requirements for DKMS as for the requirements for verifiable 
  claims. For DKMS we need very simple, extensible key description 
  semantics that enables key owners to identify and describe their 
Christian Lundkvist:  Question about the updated terminology: 
  authentication and authorization.
Drummond Reed: An inititial reaction is that it's out-of-scope 
  for the DID spec to define the semantics of "authentication" and 
  "authorization" at any scope beyond interaction with the target 
  ledger for updates to the DID document itself.
Manu Sporny:  Should never use some authentication credentials on 
  the web and use the same credential to do other things (loan).
  ... "authentication credential" there are many ways to 
  authentication and there will be many ways to authentication 
  ... keys shouldn't be doing double duty.
Drummond Reed: I want to clarify that Digital Bazaar has proposed 
  a set of changes. They are not "changes" until they are accepted 
  by the consensus of the group. That's the whole point of this 
Christian Lundkvist:  Two buckets of keys. Should there be a 
  general bucket?
Ryan Grant: 
Drummond Reed: I think the larger architectural issue here is 
  whether the DID spec should be "key-description-centric" or 
Manu Sporny:  Authorization bucket, these are the entities that 
  are allowed to do things on behalf of me (delegation) and the 
  ways they can authenticate are x,y,z.
Drummond Reed: Manu is arguing for key-action-centric, i.e., keys 
  are annotated for what they can be used for. So it starts to 
  embed key usage policy in the key descriptions. I'm worried about 
  that because of the slippery slope that @nage refers to.
Nathan George: Unfortunately the separation of concerns here 
  isn't always clean (this relates to ledger membership and 
  transaction endorsement) which depending on how the ledger works 
  muddies this water
Dave Longley: This sounds like we should hash it out in a 
  specific github issue
Kim Hamilton Duffy: +1 To dlongley
Drummond Reed: Ok
Manu Sporny:  General design: make the buckets do only one thing. 
  So there may be a need for a new bucket for new things. E.g. use 
  case to issue credentials/ this is how you can authenticate of 
  the DID. If you want to modify, these can do it. But, allow these 
  keys have access to a house, not necessarily something you put in 
  the DID document. Might be in a service provider (e.g. Nest)
  ... need to be specific about what these fields can do, so we 
  don't create security vulnerabilities.
Nathan George: Consider the endorsement/ordering model of 
  something like Hyperledger Fabric compared to the smart contract 
  model of something like uPort and negotiating the semantics of 
  key posession vs authentication (hopefully) becomes more clear
Dave Longley: "Authorization" field tells you how to construct a 
  "capability" that you can submit that will let you do something 
  specific. .... authenticationCredential field lists verification 
  information for authenticating as the entity that a DID 
Drummond Reed: I definitely would like an education on "ambient 
  authority security issues"
Christian Lundkvist:  I'd like to make the system flexible for 
  permissionless innovation
Dave Longley: "Authorization" field can therefore specify a 
  capability like "issueX"
Kim Hamilton Duffy:  Like this approach. The unclear part of DID 
  spec, is around service points.
Nathan George: Credential repository in the DID Document???  
  (this needs to be explained and defended more directly)
Drummond Reed: To Kim's questions, no, service endpoint 
  definitions are supposed to be independent of any particular DID 
  method. Each service type should be described in a separate 
  Service Description.
Nathan George: Again adding semantics into the DID Doc will cause 
  least-common-denominator semantics issues
Dave Longley: Nathan, yes, original data model design included 
  the ability to include credentials in the DID document ... DID 
  document can be a "Verifiable Profile"/"Entity Profile" in the VC 
Nathan George: Ugh
Manu Sporny: +1 For putting service links in service description 
Dave Longley: +1
Manu Sporny: So you can use them across all DID Documents...
Nathan George: I believe that most semantics should be moved to 
  service specs and handled there, putting them in the DID Document 
  means that semantics must be supported in some universal way 
  (including to everyone who can see that document)
Nathan George: If you put it in a service then the service can 
  discriminate depending on who is talking and why
Nathan George: That interaction is taking place
Drummond Reed:  Need a consistent way to describe keys associated 
  with the DID. And we won't know all the use cases for them.
Daniel Buchner:  There is certainly a concern around what keys 
  can be used for what and when.
Manu Sporny: +1 To DID Document
Mike Lodder: Yes DID document +1
Dave Longley: +1 To DID Document
Kim Hamilton Duffy: +1
Joe Andrieu: +1
Chris Webber: DIDDoc
Chris Webber: +1, DID Document seems good to me :)
Nathan George:  Every ledger who tries decentralized identifiers, 
  they have different ways their ledgers work. transaction 
  semantics bleed into the DDO objects and interoperability is 
Manu Sporny: +1 To not letting transaction semantics bleed into 
  DID spec.... 
  ... there are other ways of authorization than key, need to 
  make sure doesn't bleed into authorization or transaction 
  semantics. What is the decoupling btwn ownership of Identity and 
  transaction semantics.
Drummond Reed: All good. Kim and Christopher, for the minutes, I 
  would like to note that it appears we have general consensus 
  around moving from the term "DDO" to "DID document" (or the 
  verbal shorthand "DID doc"), and that we will start using this in 
  the spec and documents about DIDs such as the DID Primer.
Joe Andrieu: I'll give my report here: No real progress since 
  last report, but I would like to get feedback at RWoT on a first 
  draft of the 15 steps in my engagement model. That's my current 
  deadline for creating something to get initial feedback on.
Christopher Allen:  Authorization/authentication not in the DID 
  doc, but somewhere else, that is also important.
Christian Lundkvist: Very good points by nage - a lot of times 
  what can be expressed in the "authorization" parts in the DID doc 
  cannot be enforced by the ledger
Dave Longley: "Proof of ownership" suggests ambient authority ... 
  better to be really specific about what one is authorized to do 
  once they have authenticated using a particular credential.
  ... Services can be static document and not always Rest or 
  other Api.
Kim Hamilton Duffy: JoeAndrieu - is it the usual link? I'll dig 
  it up
Dave Longley: And to christopher's current point ... "particular 
  credential" doesn't just mean "digital signature using a key".
  ... not everything is going to be a simple signature. new 
  security standards, there are new things that don't have 
  traditional... btc block, some hashes, composite things acting as 
  a signature.
Joe Andrieu: Is there a usual link?
Christian Lundkvist:  A global state machine puts you at an 
  advantage for coupling semantics into this problem, but 
  introduces interesting challenges around disclosure [scribe 
  assist by Nathan George]
Dave Longley: So the capability model we're going for is: "the 
  DID doc says these are all of the capabilities a client can 
  construct ... if you're able to construct these (you have the 
  necessary credentials), then you have the authority to use them 
  to do things."
Kim Hamilton Duffy: Joe Andrieu,  this one? 
Joe Andrieu: There's nothing yet ready to review.
  ... biometric as part of a series of authentication methods.
Nathan George: The debates around system identities vs 
  transaction identities at Hyperledger have convinced me that 
  keeping identity semantics different from credential semantics 
  different from ledger transactions is going to either save us or 
  condemn us
Joe Andrieu:  Will have stuff to review at Rebooting Web of 
Drummond Reed: @Dlongley I agree with the general pattern of 1) 
  apply authentication policy followed by 2) apply authorization 
  policy. But I'm arguing that those two subjects are so rich and 
  varied and evolving that we should limit the scope of the DID 
  spec to: 1) standardizing extensible key descriptions (for any 
  purpose), 2) then defining a small set of SPECIFIC authentication 
  and authorization policies that can be applied to DID document 
Dave Longley: "Keys" may not even come into the picture 
  (Christopher's point), so we have to be careful with that.
Drummond Reed:  Made points in the chat comments.
Joe Andrieu: +1 Drummond. DID authorizations should be wrt to the 
  DDO / DID Doc only
Nathan George: I agree identity semantics are not the same as key 
  posession (but can be easily confused by systems that don't need 
  a difference)
Joe Andrieu:  Agree that authorizations should always be related 
  to the DID doc itself or the entity the DID refers to (this is 
  Christopher Allen's use case for authorizing issuance). [scribe 
  assist by Dave Longley]
Ryan Grant:  Question: is there an intention to move away from 
  the 'writeAuthorization' field?
Drummond Reed: @Dlongley Yes, replace "keys" with "proofs" in 
  everything I said.
Christopher Allen: Don't forget to register 
Manu Sporny:  Yes, no more 'writeAuthorization'... just 
  'authorization' and capabilities that entities have IF they 
  provide appropriate proofs.
Drummond Reed: I disagree - that's dictating policy.
Thanks all.
Nathan George: Ultimately an oracle of truth needs to validate 
  the authorization, which is where the semantic barrier between 
  the DDO Doc and the ledger transactions breaks down
Nathan George: We need some time to let that cook so we don't 
  introduce too much policy where mechanism is enough
[SIP/sip.linphone.org-0000030f], DanielBuchner 
  [SIP/], Drummond 
  [SIP/], nage [SIP/sip2sip.info-00000314], 
  kimhd [SIP/], Christian_Lundkvist 
  [SIP/], rgrant [SIP/], 
  AndrewHughes [SIP/], heathervescent 
  [SIP/], JoeAndrieu 
  [SIP/], AdrianGropper
Christian Lundkvist: Nage - agreed with the authorization stuff
[SIP/sip.linphone.org-0000030f] has left the conference.
Ryan Grant: Nathan, thanks for thinking about the impedence 
Received on Tuesday, 19 September 2017 18:19:08 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:45 UTC