W3C home > Mailing lists > Public > public-credentials@w3.org > April 2015

Credentials CG Telecon Minutes for 2015-04-14

From: <msporny@digitalbazaar.com>
Date: Tue, 14 Apr 2015 14:05:22 -0400
Message-Id: <1429034722017.0.20341@zoe>
To: Credentials CG <public-credentials@w3.org>
Thanks to Brian Sletten 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 Community Group Telecon Minutes for 2015-04-14

  1. Use Cases
  2. WebAppSec Credential Management API
  3. Credentials/Badges Vocabulary Update
  1. Switch the primary use cases document over to the micro-use 
    cases approach, concentrate all future use case work into that 
  Manu Sporny
  Brian Sletten
  Brian Sletten, Kerri Lemoie, Manu Sporny, Nate Otto, Dave 
  Longley, Sunny Lee, Gregg Kellogg, Adrian Hope-Bailie, Eric Korb, 
  Brent Shambaugh, Joe Kaplan, Laura Fowler, Rob Trainer, David I. 
  Lehn, Hassan Almas

Brian Sletten is scribing.
Kerri Lemoie: Sounds good
Manu Sporny:  Let's change the agenda order since Sunny has to 
  drop off early.

Topic: Use Cases

Manu Sporny: 
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.
Nate Otto: I like it
Manu Sporny:  I am hearing generally positive comments on the 
Kerri Lemoie: +1
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 
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.
Kerri Lemoie: Adrian is very quiet - or its me.
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.

Brian Sletten: +1
Dave Longley: +1
Manu Sporny: +1
Gregg Kellogg: +1
Nate Otto: +1
David I. Lehn: +1
Kerri Lemoie: +1

RESOLUTION: Switch the primary use cases document over to the 
  micro-use cases approach, concentrate all future use case work 
  into that document.

Nate Otto: Ok, added a quick Login use case to the doc if you 
  want to take look.
Manu Sporny: Thank you NateOtto :)
Kerri Lemoie: Nice work on this doc!

Topic: WebAppSec Credential Management API

Manu Sporny: Initial email to list is here: 
Manu Sporny: The proposed spec is here: 
Manu Sporny: WebAppSec use cases are here: 
Manu Sporny: Interesting "future work is here": 
Manu Sporny: Technical Review part 1 is here: 
Manu Sporny: Technical Review part 2 is here: 
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 
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]
Nate Otto: Thanks, dlongley
Eric Korb:  Thanks Manu. This is what I was looking for. We need 
  an api and working with them would be great.
Kerri Lemoie: :)
Manu Sporny:  We don't want to go down the Formal Objection 
Dave Longley:  We just want to let them know that they don't have 
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.
Received on Tuesday, 14 April 2015 18:05:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:45 UTC