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
... 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 progress ✪
... 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) ✪
... 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] ✪
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 now ✪
Ryan Grant: I don't have a specific problem with the current proposal ✪
... 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 ✪
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 along ✪
... 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 today
... 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 manager
... 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 type
... 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 credential
... they call a javascript api that looks like the credential management api and pass it a new type of credential we call a webcredential
... 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 in"
... 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
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 today
... 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 going
... 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 about
... 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 identifier ✪
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 considered
... 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 api. ✪
... 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 machine? ✪
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 integrations
... 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: 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