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

[MINUTES] W3C Credentials CG Call - 2017-08-22 12pm ET

From: <msporny@digitalbazaar.com>
Date: Tue, 22 Aug 2017 13:33:25 -0400
Message-Id: <1503423205292.0.8748@zoe>
To: Credentials CG <public-credentials@w3.org>
Thanks to Nathan George 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-08-22

  1. Administrivia - Dialing In
  2. Introductions
  3. Mission Statement Review
  4. Credential Handler API (and polyfill)
  Kim Hamilton Duffy and Christopher Allen
  Nathan George
  Nathan George, Kim Hamilton Duffy, Manu Sporny, Moses Ma, Mike 
  Lodder, David Chadwick, Dave Longley, Lionel Wolberger, Ryan 
  Grant, Adam Sobieski, Chris Webber, Frederico Sportini, David I. 

Nathan George is scribing.

Topic: Administrivia - Dialing In

Kim Hamilton Duffy:  Manu, please go ahead and start and I'll add 
  agenda references as we go
Manu Sporny:  To make the connection process simpler, if you put 
  your first name and last name on the SIP client it will 
  automatically identify you
Kim Hamilton Duffy: IRC cheat sheet: 
  ... if you're calling in via phone, it costs money, where the 
  sip does not
  ... when we have a lot of people on the call it can come to a 
  significant amount of money
Moses Ma: Which sip clients do you recommend?
  ... please use a SIP client if you can.  If you're having 
  problems participating, you may use the phone numbers, but please 
  use a sip client if you can
Kim Hamilton Duffy:  Hey, your mic changed [scribe assist by Manu 
Moses Ma:  Are there clients that you recommend?
Manu Sporny: Kimhd, your audio is super faint
Kim Hamilton Duffy:  We will update the connection instructions 
  so that the sip path is the path we encourage
  ... we hope this will help with the usability
Mike Lodder:  I reported issues with the SIP client
Manu Sporny:  Linphone and jitsi seem to work for most people
  ... it can be difficult but once it is running it does 
  typically work
  ... you can test this number at any time to see if it works
Kim Hamilton Duffy:  We have a lot of action item statuses to ask 
  ... and some work item status items to ask about
  ... DavidC will be talking about privacy and security 
  requirements as well
  ... please let me know if there are other agenda items you'd 
  like to discuss

Topic: Introductions

Kim Hamilton Duffy:  Intoductions and re-introductions.  Mike, 
  would you please introduce yourself to the group?
Mike Lodder:  I am Michael Lodder, and I'm a cryptography 
  engineer at Evernym
Kim Hamilton Duffy:  Mike has been on some threads about data 
  minimization and selective disclosure, thanks Mike
Kim Hamilton Duffy:  I can update the connection instructions 
  with good SIP clients and other instructions
  ... the next action item is to send an proposal for how the 
  DVCG integrates
  ... no objections were raised by last friday
  ... the thought is to have them continue as an informal task 
  force to help us address the crypto issues
Manu Sporny: Draft Mission Statement 
David Chadwick:  There was an issue I raised on the web page that 
  we haven't kept the idea of "user control", and I suggested a 
  modification to the statement to insert these words
Kim Hamilton Duffy:  We are also looking for any remaining 
  objections on the mission statement
  ... the next agenda item is to approve that mission statement
Kim Hamilton Duffy: Scribe list: https://goo.gl/WVHuDh
  ... we will also be adding a subscribe button on the page, and 
  as seen earlier in the call we have an updated scribe list (at 
  above link)
  ... please feel free to add comments or reach out to me if you 
  need to be removed from the list or have any other issue
  ... we are hoping to do a fairer algorithm so that the burden 
  doesn't unfairly fall on a few people
Kim Hamilton Duffy:  We have some follow up items around news and 
  verifiable claims topics
  ... we would like engagement from journalists to talk about 
  what they would like
Manu Sporny:  Evan from the NYT came to talk to us about this, 
  and we were happy to get him an update.
  ... we would like to follow up with him and contacts at Getty, 
  Associated Press and Reuters
  ... I'll take an action item to follow up with him on email 
  CC'ing Kim and Christopher as well
Moses Ma: We need a mission statement for the journalism effort?
Kim Hamilton Duffy:  I have a goal to find more contributors for 
  key work items we have committed to
  ... I'd like to describe the state of them and which items need 
  more assistance
  ... please speak up to volunteer
Kim Hamilton Duffy:  Life cycle for verifiable claims is making 
  ... it isn't clear if we need additional people driving it, but 
  we'd like more reviewers
  ... the next one is Privacy and Security requirements for the 
  credentials ecosystem
  ... today we will discuss more about this
  ... The DID spec, I'm concerned about because we have a lot of 
  interest but we need more people driving it
  ... we would like more people or set of people driving it
Manu Sporny:  What this spec likely needs isn't a project manager 
  type person (they tend to have difficulty triaging items from a 
  technical perspective)
Dave Longley: +1 For running down that list.
  ... the best thing to focus on here is probably "every single 
  item that goes into a DDO"
Nathan George: +1 To the DDO next step - there are plans to do 
  this at RWoT and the new draft has been opened up for feedback
  ... we have been waiting to see how to engage, but want to make 
  sure we're not waiting for things that can be discussed in the 
  short term
Kim Hamilton Duffy:  We have a lot of people listed as champions, 
  but who is pushing the work items, reviewing issues, and 
  scheduling out of band meetings?
Nathan George:  I know Drummond is interested in that as well, 
  but he's been on the road. We should reach out to both of them to 
  see what their plans are on that. [scribe assist by Manu Sporny]
Nathan George:  I think there is more of a communications gap 
  than anything else. [scribe assist by Manu Sporny]
Mike Lodder: +Q
Nathan George:  Mentioned that Drummond is interested in this 
  topic as well
KimHD is reaching out to Drummond and Christopher to try to close 
  the communications gaps here
Kim Hamilton Duffy:  Data minimization and selective disclosure
  ... we have some specialized signature suites here
  ... people have volunteered to help here, and I think we'll be 
  good at this
  ... Lionel has volunteered to help drive some things here
  ... and Christopher and I would like to help where we can
Kim Hamilton Duffy:  Then the last item is browser APIs and 
  ... which is the next agenda item after the mission statement

Topic: Mission Statement Review

Kim Hamilton Duffy: https://goo.gl/sNs2vl
Kim Hamilton Duffy:  David, can I have you talk to your comment 
  on the mission statement?
Lionel Wolberger:  Lmk if the select-dis/data-min is on the 
  agenda, or did I miss that [scribe assist by Lionel Wolberger]
David Chadwick:  What here differentiates that we want the person 
  or subject or user to be in control of this information, and how 
  the user stays in control of the system
Kim Hamilton Duffy:  Some concept of user-centricity or user 
  control is the big advantage to the approach we are thinking 
  about we didn't cover
  ... I'll add something about that here and lets iterate on that 
  on the mailing list
  ... rgrant has asked about privacy as a main objective and how 
  we talk about the consequences of data minimization in a way that 
  highlights the privacy features
Ryan Grant:  I remember there being some other question here that 
  I was responding to that I don't see here in the comments now
  ... I wished to express that it is still a main objective (the 
  content this comment points to is now missing)
Kim Hamilton Duffy:  I think I know what that was referring to 
Ryan Grant:  I don't have a specific problem with the current 
  ... if others think their issues are resolved, then I think I'm 
  okay with this
Kim Hamilton Duffy:  I'll send another draft and we'll extend the 
  feedback deadline a bit more
Manu Sporny:  I don't want to prolong the discussion about the 
  mission statement, I don't think any change we're discussing will 
  really change what the group is doing
  ... as a result of that user control
Lionel Wolberger: +1 Manu, to closing the mission statement
Kim Hamilton Duffy:  I'm also inclined to keep that, because 
  self-soveriegn identity is a form of management but this also has 
  a larger idea of how credentials are managed generally
Manu Sporny:  If there are no other concerns lets get it added, 
  close the mission statement and move on

Topic: Credential Handler API (and polyfill)

Dave Longley: 
Kim Hamilton Duffy:  Lets have dlongley and possibly manu talk to 
  us about browser polyfill
Dave Longley:  Here are some slides that you can use to follow 
  ... this is about a browser, web API to store credentials and 
  share them across websites
  ... one is for performing an implementation and the other to 
  make a spec so that it can be implemented natively in browsers
  ... after the javascript for websites to use, then is a spec 
  for browsers to implement
  ... we have gotten quite a bit work done on the implementation 
  side of things
  ... there are links at the end to see a demo of where we are at 
  ... we have named this api the "credential handler" api
  ... we have an existing api called the credential manger api
  ... this api enables people to get and store credentials, but 
  we are talking about things like passwords here
  ... this is a way to get access to the browsers password 
  ... and it is limited to same origin credentials like passwords
  ... updating it requires updating the browser for each type of 
  credential that you can think of
  ... we want anyone to be able to come in, create a new 
  credential and then go from there
  ... right now the extensibility is limited in that sense
  ... we are creating an interface for creating a new credential 
  ... this new api will create a new single type of "web 
  credential" that lets third party websites handle requests for 
  this type of generic web credential
  ... which would let innovation on what types of credentials 
  exist get pushed out to the edge
  ... in this work we would define one subtype to start with, a 
  verifiable profile
  ... we have this concept of a verifiable profile which is a 
  collection of credentials that contain claims and assertions 
  about attributes that entities have
  ... this new type of credential could be passed around to 
  different websites
  ... the main take away is : you do not need to update the 
  browser when you come up with new credentials that fit this 
  model.  Native browser code should work with it
  ... In slide 4 I talk about the design of how this works
  ... some people might know this as a digital wallet
  ... this could be on your device or in some cloud service
  ... for the different types of credentials and identities that 
  you might have
  ... this API will ask permission from the user to manage a 
  credential for you
  ... this does not mean you will be the only credential repo for 
  the user, but you can make you site a choice when a user wants to 
  make or store credentials
  ... you can register different hints that will show up in a 
  selector at a later point in time
  ... in slide 5 we talk more about the purpose of those hints
  ... here a user is visiting a website that wants to issue a 
  ... they call a javascript api that looks like the credential 
  management api and pass it a new type of credential we call a 
  ... its subtype is VerifiableProfile.  The website generates it 
  with the attributes you wish to have stored
  ... when it is called the user sees a chooser ui with the hints 
  that were previously registered
  ... so on the screen you see "this website wants to store 
  credentials for you, pick which identity you wish to store this 
  ... once you click on one of those what will happen is, the 
  credential will be passed through a credential mediator, which 
  will take what you're trying to store, look up the handler or 
  repository and pass it that credential
  ... then it will load in your browser and perhaps show some ui 
  to help you store it (what ever the repostiory needs to do, where 
  you delegate to that repo website of your chosing)
  ... on slide 6 the use case is a user is visiting a site that 
  needs credentials
  ... they are querying for a verifiableprofile with a specific 
  set of attributes
  ... or a specific type of credential
  ... what is important here is that you will be shown the same 
  choser, to select a particular repository or identity of their 
  choice to forward the request to
  ... the browser doesn't have to understand the query, it is 
  pushed to the repository, which is responsible for helping the 
  user provide the ui to help them make that choice
  ... once the user has composed that verifiable profile, it goes 
  back through the mediator with the polyfil and gets back to the 
  website so that they can grant you access to that action
Lionel Wolberger:  +1 Nice modular architecture [scribe assist by 
  Lionel Wolberger]
Dave Longley:  This brings you through the type of steps to 
  needed, to get to the right places to get the needed items to get 
  and present these credentials and have a place to store and 
  manage them
  ... the point of the API is to push the functionality needed to 
  support this to digital wallet providers
  ... there are two polyfills involved to make this work (if 
  you're technically minded please ask about this)
Moses Ma: Question: would it be possible to extend this system to 
  support email, to address phishing and spam?
Dave Longley:  The next links are rough demos of what has been 
  implemented so far
  ... it should work in Chrome and is rough, but you can go to 
  these sites in order and install a digital wallet, get a fake 
  credential and then go to a site and present it
  ... on slide 8 is the meat of what we'd like to talk about 
  ... we've logged some issues around what we'd like to see today
  ... there are some privacy related issues that are interesting
  ... we'd like to talk about how a verifiable profile is 
  indicated as part of requesting credentials
  ... we need to be able to prove that you are the owner of that 
  profile when you present it
  ... something else that is important on that is there is a 
  piece of information about the destination for where you are 
  sending the profile, because it has privacy implications
  ... our repositories don't need to know where you are sending 
  the profile so far, so issuers don't need to know that 
  information (we don't want to compromise on that)
  ... but it also supports the notion that perhaps the repo 
  doesn't know, where they only know the query but not where it is 
  ... knowing could help them decide what to send, but they don't 
  have to know
  ... should we consider the idea that repositories don't get 
  this information?
  ... they either need this information or perhaps a blinded 
  version of this information
  ... in the first issue, that is essentially what we're talking 
  ... if they are not going to perform the signature, then the 
  responsibility falls to the broswer or the polyfill and that has 
  political ramifications
  ... the browsers would rather not add more code for a lot of 
  security and privacy reasons
  ... asking them to do so is a "big ask"
Mike Lodder:  You were asked about blind signatures, CL 
  Signatures are used there often... [scribe assist by Manu Sporny]
Mike Lodder:  The CL signature scheme allows a user to blind a 
  signature to prove posession without revealing the correlation 
Dave Longley:  We might be looking for something that is lighter 
  weight as well
  ... for example a simpler mechanism for blinding might be a 
  random number that can be used for a crytpographic hash
  ... there are a number of different techniques that could be 
  ... I want people to be aware that implementation complexity on 
  the user and browser sides will require us to convince people of 
  what needs to be implemented
David Chadwick:  This introduces a new party that has to be 
  trusted with the repository into the ecosystem
  ... we don't want this new party to piece together what the 
  user is doing and where they are going
  ... if the repo is directly under the users control, the local 
  repo could enforce items to help prevent disclosure
  ... which would all have correlating handles
  ... there are some interesting issues here.  Have you 
  considered local repositories?
Dave Longley:  Yes, we've considered that.  This API is a web 
  ... in this context we'd be talking about building this 
  directly into the browser, which can create monopoly issues and 
  other troubles
  ... for a non-browser implemented api it means we have to think 
  of it as another party even when it is local
Ryan Grant:  How would the protocol or message structure change 
  if you were passing the data to another instance on your own 
Dave Longley:  Hopefully it wouldn't change, and how it happens 
  would be under the control of the browser, and they could chose 
  to do something proprietary
  ... but there is no reason why they would need to change (it 
  would happen outside W3C space)
Ryan Grant:  Could you qualify whether anything that isn't over a 
  socket is outside of W3C, or are you talking about more native 
  integration?  Aren't there options in between?
Dave Longley:  Browsers are removing native features where they 
  agree on features
  ... there are ebbs and flows here, but we are on stronger 
  ground when we're not talking about browser and OS level 
  ... when we talk about services and websites they are more 
  willing to come to the table and talk standards
Ryan Grant: Okay, my read is that defining message structures 
  would be sufficient.
  ... sometimes that happens, but I think we're talking about a 
  different API at that point.  The hope is to have an API in place 
  that helps inform that integration discussion
Manu Sporny:  I want to underscore what dlongley has said
Lionel Wolberger:  Nice acribing, nage <clap, clap> [scribe 
  assist by Lionel Wolberger]
Lionel Wolberger:  Scribing [scribe assist by Lionel Wolberger]
  ... the design for this API has been influenced by the reality 
  of what has been happening at the W3C over the last 6 years
  ... it has been designed so that the browser manufacterers will 
  be comfortable with this approach and it will be easier to say 
  "okay" to this direction, building on work done like the 
  webpayments and credentials apis
  ... it is also done in a way that is intended to protect the 
  person's privacy, aligned with the mechanisms used to protect a 
  user doing credential polyfill
  ... there are a lot of demands on this api, and we think it 
  provides the right balance
  ... but there is a lot here to unpack, and we expect it will 
  take some time to articulate the simple and deep answers to these 
  types of questions
Dave Longley: 
Dave Longley: Please add issues or comment on existing ones here
Kim Hamilton Duffy:  Please again look through the repos and 
  issues and comment
  ... I'll follow up over email on the action items and issue we 
  talked about
  ... let me know if you need more assistance on your work items
Dave Longley: If you're technical, please take a look at the 
  code/demos here: 
Dave Longley: And provide feebdack
  ... Thanks everyone, see you next week!
Received on Tuesday, 22 August 2017 17:33:48 UTC

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