Manu Sporny: The Micro use cases document has been updated with all of the content from the current document. The move over happened without incident. Some concern about whether we had the right number of phases. Nate has commented, Dave Longley has commented, Sunny and Kerri have commented. Let's hear from each of you about the document, if you have any concerns, if you think this is a good approach. ✪
Kerri Lemoie: I like this format a lot. It makes sense, it's easy to read. Similar to other Use Cases doc. I put some comments in. We don't have to get to all of them today. I really like this and think it will help those who are coming in. ✪
Nate Otto: My linphone is crashing over and over -- can I call in on the regular phone? ✪
Manu Sporny: Thanks for your comments, Kerri. They are pertinent and good and need to address them. ✪
Dave Longley: +1 What Kerri said. Once we get it into a web page, it will be even more readable. It's a big improvement. ✪
Sunny Lee: +1 What Kerri said. I read it thoroughly. It was cohesive and read well. Our use cases fit well here. ✪
Manu Sporny: Does everyone feel comfortable on making this our use cases document? Are these operations ordered properly? Can we take this document, clean it up and in a month's time have something that we are comfortable pointing to when what other people to join the work formally. ✪
Nate Otto: I added one set for recipient-initiated sharing flow, which then duplicates 2 steps from the consumer-initiated flow. Is this useful, or should they be refactored. ✪
Gregg Kellogg: Are we decided on using Google Docs or should we use ReSpec? ✪
Nate Otto: +1 Moving back to ReSpec in order to publish, but I do like Google Docs for collaborating at this scale. ✪
Manu Sporny: We find that Google Docs is easier to collaborate with comments. Eventually, Web Annotations will help. This stuff needs to be in a certain format. We need to timestamp these documents when we put them out. My expectation is that we will collaborate in the Google Docs until things settle down and then we'll move over to the ReSpec version and that will be our time-stamped document. ✪
Brian Sletten: Are we suggesting that there could be other use cases emerging in the document? [scribe assist by Manu Sporny] ✪
Manu Sporny: We will be adding to the document moving forward. Tim Holborn wants to add a more specific online bullying take down language. ✪
Manu Sporny: There is still a decent amount of work to the document. ✪
Gregg Kellogg: Should we cover the WebAppSec use cases to help address their needs? ✪
Nate Otto: Thanks to Manu & Dave for digging into the WebAppSec document on such short notice. ✪
Dave Longley: The WebAppSec spec looks like it was created thinking Login use cases were key, but based on our experience is that Login credentials are simply one tiny use case in a sea of use cases. ✪
Manu Sporny: That means we should have a set of login uses cases in our document. ✪
Adrian Hope-Bailie: I wanted to say that this can swing both ways. What they look at as a credential is a user name and password. We look at it as a signature. Maybe there is scope for us to expand our definition of credential to be login credential. ✪
Dave Longley: I think we want any api to support both uses. We can get people to adopt the api before they necessarily adopt the credentials work. However, I don't think we want username password as a credential to persist as a long term solution because it isn't a great credential. ✪
Manu Sporny: Yes, we need Login use cases. Do they go in WebAppSec documents? Credentials documents? Both? ✪
PROPOSAL: Switch the primary use cases document over to the micro-use cases approach, concentrate all future use case work into that document.
Manu Sporny: To summarize: There's a lot of information here and will continue to be so over the next couple of weeks. In general, this is what is going on. The WebAppSec is considering publishing a FWPD of credential management. ✪
Manu Sporny: There is disagreement with how much overlap there is between this initiative and the Credentials CG and what the Web Payments IG wants. ✪
Manu Sporny: There are a number of issues that I have raised so far. Adrian has raise. Dave Longley has raised. A lot of other people have not weighed in yet. The call for consensus started last Friday and ends this Friday. For those that care about the CG work it is important that you get your mind wrapped around what is going on here. The problems, potentials solutions and the path forward. ✪
Manu Sporny: Dave Longley, do you want to go down the list? ✪
Dave Longley: My read on this spec that they are calling for consensus. I think it is primarily designed to allow web pages access to password managers and are trying to be forward-looking about potentially doing more with credentials in the future. I think the short-term efforts are not as overlapping, but that the future work definitely will and won't work well. ✪
Dave Longley: There is no mechanism to sync credentials between browsers. Browser-based password managers don't do this now so they don't think it is a problem. We don't want to build specs based upon what is only available now. We want to avoid credentials getting locked into browsers. ✪
Dave Longley: Allowing plugins to replace part of the browser API for credential management might help migration in the short term, but has security implications. ✪
Dave Longley: Let's make the core api work the right way rather than design for what is now and work around it in the future. ✪
Dave Longley: The api doesn't really seem to be about killing the password. They do talk about federated logins via super providers (Twitter, Facebook, Google). This will guarantee super providers because developers have to iterate over them. Mike West suggests maybe you can specify which providers you support, the sites can specify who they support and the browsers can show you the overlap/intersection. Our approach suggests t ✪
Dave Longley: And doesn't need to be handled specially. ✪
Dave Longley: The spec assumes that there will be two different apis in the future. It will be difficult for us to work with their api without creating a new api (and therefore two different apis). It would be difficult to support (if not impossible) the use cases we have. ✪
Manu Sporny: These are just the high level issues with this spec. The second email above goes into a number of issues we have with the design. Does anyone have any questions? ✪
Nate Otto: Thanks, dlongley, your explanation over email and audio was fairly clear. ✪
Eric Korb: My biggest concern is how much impact this will have on us if they push forward without our consideration. Where are we in our stage vs where they are in their stage in a WG? ✪
Manu Sporny: It's unclear how damaging this could be. If they don't listen to our concerns, we could have two different credential apis. One doing login/sso credentials and ours digitally-signed credentials. That's kind of the worst case scenario. It's Google. They could ignore us and be very successful getting it into Chrome. They are also close with Mozilla which means it could be shoe-in to the platform. We want an api built into t ✪
Manu Sporny: It won't be good if they don't want to collaborate. Strategy should be: How can we make the minimum number of changes to what Mike is proposing to ensure that the kind of credentials we are talking about and the ability to store them in a vault is supported as a first class feature in their api. ✪
Manu Sporny: That would be a huge win for the Credentials CG because it would be in the browser before we expected. It would be a win for them because we have done a lot of the future work for them. And they would get a few more CG/WGs using their api. ✪
Nate Otto: WebAppSec seems like a good group to be doing the part of this that has to do with the browser API. If they want to push on the browser vendors, we should do our best to show how our use cases are valuable and explain what it means to have credential == signed claim about an identity/identifier. ✪
Manu Sporny: We know what kind of changes we'd like to see to their api. The question is whether they will listen and want to slow down their work or not. There is still quite a bit of miscommunication. I don't think they are up to speed on what we are doing. They haven't engaged yet despite multiple attempts (last fall). ✪
Kerri Lemoie: Does w3c have a process of arbitrating this? ✪
Manu Sporny: If people stay silent, the FPWD will go through and we'll have to fix it later. ✪
Manu Sporny: If you agree and care about this stuff, send in an email. ✪
Brent Shambaugh: Will anyone see them in person? ✪
Nate Otto: Do you have to sign up on the public-webapps mailing list before your messages to that address would be visible? ✪
Manu Sporny: In the next month, we need to see how to collaborate and get them up to speed. We need to get the staff contact up to speed as well. ✪
Nate Otto: No, it's a public list, it may just take a few minutes to clear your first email to the list [scribe assist by Dave Longley] ✪
Manu Sporny: We don't want to go down the Formal Objection route. ✪
Dave Longley: We just want to let them know that they don't have consensus. ✪
Adrian Hope-Bailie: I agree. We need to emphasize the win-win nature of us working together. ✪
Manu Sporny: Any other questions or concerns about this stuff? ✪
Topic: Credentials/Badges Vocabulary Update
Nate Otto: Badge Alliance is finalizing 1.1 version, we're waiting for input on the canonical URL. After that, we're going to move forward to 2.0 and see what it means to do badges with Linked Data. ✪
Manu Sporny: Any other business before we close the call? ✪
Manu Sporny: The highest priority is responding to the email and requesting coordination before the FPWD. ✪