16:05:45 <RRSAgent> RRSAgent has joined #webauthn
16:05:45 <RRSAgent> logging to http://www.w3.org/2017/03/08-webauthn-irc
16:05:47 <trackbot> RRSAgent, make logs public
16:05:47 <Zakim> Zakim has joined #webauthn
16:05:49 <trackbot> Zakim, this will be
16:05:49 <Zakim> I don't understand 'this will be', trackbot
16:05:50 <trackbot> Meeting: Web Authentication Working Group Teleconference
16:05:50 <trackbot> Date: 08 March 2017
17:41:34 <weiler> weiler has joined #webauthn
17:42:15 <weiler> agenda: https://lists.w3.org/Archives/Public/public-webauthn/2017Mar/0126.html
17:42:19 <weiler> weiler has changed the topic to: agenda: https://lists.w3.org/Archives/Public/public-webauthn/2017Mar/0126.html
17:42:27 <weiler> zakim, who's here?
17:42:27 <Zakim> Present: (no one)
17:42:29 <Zakim> On IRC I see weiler, Zakim, RRSAgent, battre, jochen___, slightlyoff, wseltzer, trackbot, adrianba, mkwst_ooo, schuki, jcj_moz
17:46:05 <weiler> RRSAgent, make log public
17:46:15 <weiler> RRSAgent, generate minutes
17:46:15 <RRSAgent> I have made the request to generate http://www.w3.org/2017/03/08-webauthn-minutes.html weiler
17:58:17 <jcj_moz> present+ jcj_moz
17:58:21 <jcj_moz> scribenick: jcj_moz
17:58:27 <weiler> present+ weiler
17:59:51 <mkwst_ooo> present+ mkwst
18:00:08 <gmandyam> gmandyam has joined #webauthn
18:00:13 <vgb> vgb has joined #webauthn
18:00:19 <Rolf> Rolf has joined #webauthn
18:00:46 <vgb> present+
18:00:52 <gmandyam> present+ gmandyam
18:01:08 <wseltzer> present+
18:01:22 <jeffh> jeffh has joined #webauthn
18:01:26 <wseltzer> zakim, who is here?
18:01:26 <Zakim> Present: jcj_moz, weiler, mkwst, vgb, gmandyam, wseltzer
18:01:28 <Zakim> On IRC I see jeffh, Rolf, vgb, gmandyam, weiler, Zakim, RRSAgent, battre, jochen___, slightlyoff, wseltzer, trackbot, adrianba, mkwst, schuki, jcj_moz
18:01:31 <jeffh> present+ jeffh
18:01:59 <rbarnes> rbarnes has joined #webauthn
18:02:29 <wseltzer> present+ rbarnes, jfontana, rolf
18:03:50 <Ketan> Ketan has joined #webauthn
18:05:13 <vgb> is ti just me or is this the quietest party ever?
18:05:29 <wseltzer> present+ christiaan
18:05:44 <wseltzer> present+ angelo
18:07:11 <wseltzer> Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2017Mar/0126.html
18:07:18 <jcj_moz> rbarnes: We've 4 open PRs on the agenda
18:07:29 <jcj_moz> ... begin with #312
18:07:57 <wseltzer> https://github.com/w3c/webauthn/pull/344
18:08:19 <jcj_moz> jeffh: (my opinion) is all expressed in there
18:08:24 <wseltzer> present+ dirk, alexei
18:08:37 <alexei-goog> alexei-goog has joined #webauthn
18:08:38 <vgb> ah, had to hang up and reconnect to start getting audio
18:09:07 <jcj_moz> jcj_moz: I've been bad
18:09:15 <alexei-goog> present+
18:09:58 <jcj_moz> jeffh: I'd go with CollectedClientPartyData and RelyingPartyUserInfo and be done
18:10:48 <jcj_moz> rbarnes: See if Kim is ...
18:10:57 <jcj_moz> jeffh: It's a really minor item, we'll resolve it
18:11:00 <wseltzer> https://github.com/w3c/webauthn/pull/348
18:11:03 <jcj_moz> rbarnes: OK, on to #348
18:11:26 <jcj_moz> Angelo: I've got a change to make that I haven't pushed up yet.
18:11:40 <jcj_moz> rbarnes: OK, on to #350
18:11:43 <wseltzer> https://github.com/w3c/webauthn/pull/350
18:11:53 <jcj_moz> Angelo: That's me, too, same situation, I've been busy on another feature.
18:12:03 <jcj_moz> rbarnes: You've a fix on your plate and you still need to fix it?
18:12:13 <jcj_moz> Angelo: Yes. It's a change on MakeCredential that needs to be merged
18:12:23 <jcj_moz> ... I'm making changes to #350 right now
18:12:47 <jcj_moz> jeffh: You'll want to merge from master into your branch Angelo
18:12:55 <jcj_moz> rbarnes : Are these going to conflict with #344?
18:13:00 <jcj_moz> jeffh: I wouldn't worry about that
18:13:10 <jcj_moz> ... 350 was not controversial ,but 348 may be
18:13:20 <jcj_moz> rbarnes: jeffh, do we need another round of review on 348 before it merges?
18:13:25 <jcj_moz> jeffh: Yes.
18:13:35 <jcj_moz> rbarnes: And you're ok with Angelo merging 350 when he's done?
18:13:42 <jcj_moz> jeffh: I have some comments on it but yes
18:13:54 <wseltzer> https://github.com/w3c/webauthn/pull/371
18:13:55 <jcj_moz> rbarnes: On to #371, jeff?
18:14:21 <jcj_moz> jeffh: This is in progress, I took the changes jyasskin asked for in 347 and applied them in here so they're consistent. vgb's reviewed that and had some comments, I fixed
18:14:43 <jcj_moz> ... At that point it looks good to him. But what I'm intending to do is there's a slew of issues that Boris submitted, and I'm working through them in this PR
18:14:52 <jcj_moz> ... Some of those issues have already been fixed by this PR and prior PRs
18:15:07 <jcj_moz> ... so I'm double-checking those and will set it up so when this merges it'll close those and add fixes for those aren't addressed yet
18:16:02 <jcj_moz> rbarnes: So that's all for PRs; going back and for reviewing....
18:16:19 <jcj_moz> ... Angelo's going to update 348/350 soon, but 350 can go ahead and land
18:16:29 <jcj_moz> ... and Jeff is still workingon 371
18:16:41 <jcj_moz> ... That concludes Agendum #2.
18:16:50 <rbarnes> https://github.com/w3c/webauthn/issues?q=is%3Aopen+is%3Aissue+milestone%3AWD-05
18:16:55 <jcj_moz> ... Agenda #3 is establishing our schedule for WD-05
18:17:04 <jcj_moz> ... Do we want to try and triage some of those here?
18:17:08 <jcj_moz> jeffh: Which are you talking about?
18:17:15 <jcj_moz> rbarnes: See link
18:18:06 <jcj_moz> Angelo: The issue regarding Credential Management, I'm trying to figure out a relationship between CM and this API. I recently chatted with dominc and mkwst who've been working on the CredMan API
18:18:15 <jcj_moz> ... mkwst will try and join next week
18:18:22 <jcj_moz> mkwst: I'm on the line.
18:18:37 <wseltzer> present+ Dominic
18:18:39 <jcj_moz> mkwst: Dominic and I are both on the call.
18:18:44 <jcj_moz> Angelo: Is Dirk here?
18:18:52 <wseltzer> zakim, who is here?
18:18:52 <Zakim> Present: jcj_moz, weiler, mkwst, vgb, gmandyam, wseltzer, jeffh, rbarnes, jfontana, rolf, christiaan, angelo, dirk, alexei, alexei-goog, Dominic
18:18:52 <jcj_moz> rbarnes: It looks like Dirk is here.
18:18:54 <Zakim> On IRC I see alexei-goog, Ketan, rbarnes, jeffh, Rolf, vgb, gmandyam, weiler, Zakim, RRSAgent, battre, jochen___, slightlyoff, wseltzer, trackbot, adrianba, mkwst, schuki, jcj_moz
18:19:05 <jcj_moz> Dirk: We're here.
18:19:19 <jcj_moz> rbarnes: Angelo, mkwst  do you guys want to take this away?
18:19:36 <jcj_moz> Angelo: I'm more of a messenger to mkwst, Dirk can you take it?
18:20:01 <jcj_moz> Dirk: Where we are currently, is that we want to move our namespace under navigator.credential.crypto and leave everything else as-is
18:20:25 <jcj_moz> ... and that we think that would be a good idea for CredMan to move under navigator.credential.bearer and leave everything else
18:20:41 <jcj_moz> ... that's where we landed from the discussion in WebAuthn
18:21:31 <jcj_moz> mkwst: Generally speaking, I think that moving things under navigator.credential.<something else> can make sense, but not sure that's the best way to make the distinction between the types of credentials you care about, and those presented by CredMan API
18:21:57 <jcj_moz> ... For the credential type you care about - ScopedCredential - could instead inherit from Credential, but not inherit from CredMan's SiteBoundCredential
18:22:26 <jcj_moz> ... SiteBoundCredential is a bad name, and I'd be happy to rename it to <SomethingElse>Credential, while leaving you all room to do what you want to with your types of credentials
18:22:45 <jcj_moz> ... Also in my opinion, at a very high level, the APIs are very similar
18:23:24 <jcj_moz> ... The way that I see things from a developer perspective, these APIs end up looking very similar - the developer wants to authenticate a user, and asks the browser for some help
18:23:41 <selfissued> selfissued has joined #webauthn
18:23:41 <jcj_moz> ... <description of how CredMan handles passwords>
18:24:11 <jcj_moz> ... <description of how CredMan handles federated credentials and handing auth tokens over to websites>
18:24:49 <jcj_moz> ... It seems to me that the work you all are doing is similar in kind to to those kinds of credentials. Instead of consulting a data store, or an external entity, you're consulting a hardware token
18:25:11 <jcj_moz> ... from my perspective a developer is going to look at those all in the same way, looking to hand something over to a server for verification
18:25:26 <jcj_moz> ... it seems to be possible to merge those, which is Dirk's option-C in the face-to-face meeting
18:25:43 <rbarnes> mkwst: link to straw-man?
18:25:45 <jcj_moz> ... I put together a very straw-man-y suggestion a long time ago that has this in it
18:26:48 <jcj_moz> mkwst: I don't want to distract from your conversations too much, so please let me know when we need to move on to something else, or when this is not productive, but. ..
18:26:59 <jcj_moz> ... The straw man I posted I think is a pretty reasonable way to look at these APIs
18:27:12 <angeo> angeo has joined #webauthn
18:27:17 <jcj_moz> ... We can re-use the APIs from the Credential Management
18:27:39 <jcj_moz> ... First we create a new Credential object, AwesomeNewCredential, and we give the prorotype a static registration method, which makes to MakeCredential
18:28:03 <jcj_moz> ... as a developer you'd call AwesomeNewCrednetial.Register and provide similar info as one would for MakeCredential
18:28:07 <rbarnes> https://gist.github.com/mikewest/ca0e488bd4393b08acf9eadfe7092e2e#file-potential-style-js-L39
18:28:09 <jcj_moz> ... This is slide #5 in the deck I posted
18:28:42 <jcj_moz> ... The second piece is that the new Credential type contains not only the new static method for Registration, but also an assertion property, so that it inverts the relationship between assertion and credential
18:29:25 <jcj_moz> ... so when you all call GetAssertion, you end up creating an assertion that is returned to the developer , and a credential property
18:29:50 <jcj_moz> ... in mind you then create a Credential object that contains an assertion, which has the information you can send to a server to bind that credential to an account
18:29:57 <jcj_moz> ... (Slide 7 by the way)
18:30:31 <jcj_moz> ... You pass in some information including the challenge and you get a Credential object back, and that Credential has an assertion proeprty, and that assertion property has the same kind of information including a signature property
18:30:48 <jcj_moz> ... which you can pass up to the server to authenticate
18:31:02 <jcj_moz> ... It's a respelling, and makes GetAssertion into a special case of the Get method
18:31:47 <jcj_moz> ... It doesn't account for the other two methods in CredMan - Store and GetUserRemediation. GetUserRemediation are no-ops for your credential types
18:31:59 <jcj_moz> ... Store is ... (slide 8)
18:32:27 <jcj_moz> ... The idea behind Store might be controvertial, but you could use Store to keep data that would be helpful for the user agent
18:32:39 <jcj_moz> s/controvertial/controversial/
18:33:14 <jcj_moz> ... Store could teach the user that there's a relationship between an Account, Origin, and Token ID, which might let us provide a more robust authentication experience for users by leading user through some sort of 2nd factor mechanism as well
18:33:34 <weiler> RRSAgent, generate minutes
18:33:34 <RRSAgent> I have made the request to generate http://www.w3.org/2017/03/08-webauthn-minutes.html weiler
18:33:39 <jcj_moz> ... Because we'd store that information, that would give us some options in the future that we don't have today
18:34:03 <weiler> chair: rbarnes
18:34:07 <jcj_moz> rbarnes: Could you comment on what the store/get would be doing in this API?
18:34:32 <jcj_moz> mkwst: Store allows us to teach the user agent that the user has an account on this website on this origin with this metadata
18:35:30 <jcj_moz> ... (This could make it possible for the UA to remember what tokens you're using)
18:36:19 <jcj_moz> Dirk: I have a clarifying question: I think you said that both Register and Get return an object of AwesomeCredential type which has an assertion within it.
18:36:21 <jcj_moz> mkwst: Yes
18:36:35 <jcj_moz> Dirk: The two types of cryptographic assertions you get are different
18:36:49 <jcj_moz> ... During registration you get a public key, and during authentication you get something different
18:37:05 <jcj_moz> mkwst: As far as the IDL is concerned, I believe the two types are quite similar
18:37:39 <jcj_moz> ... The response type from makeCredential has the same attributes as that which comes from getAssertion. Have I misinterpreted that?
18:37:59 <jcj_moz> Dirk: There was a concrete proposal to make those look the same in the API and make the RP treat them differently
18:38:34 <wseltzer> present+ Ketan, selfissued
18:38:36 <angelo> angelo has joined #webauthn
18:38:39 <jcj_moz> Dominic: Boris brought that up.
18:39:07 <jcj_moz> Dirk: What is a Credential, the key pair that is assigned to the user, or an assertion signed for the server?
18:40:07 <jcj_moz> mkwst: We have two kinds of Credentials defined in the CredMan API - Username/Passwords, and Federation, and now we're talking about a 3rd type which allows the website to .______? The credential, in my mind, is wrapping a concept that lets the website be confident in its decision
18:40:32 <jcj_moz> ... I think the Credential is a box, and you hand the box to a website and say ' do what you will' to make the kind of assertions you need
18:40:59 <jcj_moz> Dirk: When we were discussing at the F2F, one of the things we bumped into when we said there wasn't much overlap --
18:42:31 <jcj_moz> mkwst: The way (a server) decides if (a Credential) is to be trusted is different for the different types of Credentials
18:42:49 <rbarnes> q+
18:43:00 <jcj_moz> ... They are different in nature, but I think the way they are used is similar
18:43:42 <jcj_moz> rbarnes: I'm mostly onboard with this. The thing that strikes me about this is that the entire logic of GetAssertion and put it into the Get method, which is a lot more complexity than is currently resident there
18:43:53 <rbarnes> ack rbarnes
18:44:04 <jcj_moz> mkwst: The way the Get method is currently specified is a dictionary of properties that define the credential you care about
18:44:49 <jcj_moz> ... In the dictionary, for passwords there's no filtering. For federations it's already a bit more complicated.
18:45:02 <jcj_moz> ... (Origins of IDPs you trust, protocols, etc)
18:45:21 <angelo_> angelo_ has joined #webauthn
18:45:36 <gmandyam> q+
18:45:41 <jcj_moz> ... I think it's perfectly reasonable to allow the Get mechanism to accept the kinds of information you're requesting
18:45:53 <jcj_moz> ... If that includes a challenge, that seems like a reasonable thing to do
18:46:07 <jcj_moz> ... It's not any more complicated than naming it something else and passing in more information
18:46:09 <rbarnes> ack gmandyam
18:46:12 <rbarnes> q+
18:46:54 <jcj_moz> gmandyam: If I look at the existing CredMan spec, CredentialInfo has but one entry - id - why do that if we go this point? Why not make CredentialInfo to have all the members that we've described as part of ScopedCredentialOptions?
18:47:39 <jcj_moz> ... CredentialData defined in CredMan has only one entry. Why would you extend that with AwesomeCredential, when we could redefine CredentialData?
18:47:55 <jcj_moz> mkwst: (These are to be extended by the different Credential Types)
18:48:18 <angelo_> sorry my computer crashed when we started the cred man discussion. Can anyone give me a link to the deck Mike posted?
18:50:10 <jcj_moz> rbarnes: The thing you're going to pass in to Store here is pretty different than what you get back from Get
18:50:17 <weiler> RRSAgent, generate minutes
18:50:17 <RRSAgent> I have made the request to generate http://www.w3.org/2017/03/08-webauthn-minutes.html weiler
18:50:21 <gmandyam> q-
18:50:22 <jcj_moz> ... Which is the capability to get signed things, but you Get signed things.
18:50:33 <jcj_moz> ... Is there any precedent for that sort of thing?
18:50:47 <jcj_moz> mkwst: I agree that it's different. The way that Store works, the most vague part of this pretty vague straw man
18:50:49 <angelo_> Thank you for the link. I have a hard stop at 10:50.
18:51:02 <jcj_moz> ... What I'm trying to do with that part of the proposal is point to things that might be doable in the future
18:51:31 <jcj_moz> ... (Imagine a web where the website can delegate all auth to the UA)
18:51:44 <rbarnes> ack rbarnes
18:51:46 <jcj_moz> ... (Imagine making second factors look the same on all websites)
18:52:17 <jcj_moz> ... The thing I get back from Registration is different than what you get back from GetAssertion. What we care about storing is the identifier.
18:52:30 <jcj_moz> ... We want to point to this particular Key on the token, and storing that seems reasonable
18:52:45 <jcj_moz> ... but I agree that storing the Assertion makes no sense, storing the metadata seems reasonable
18:53:05 <jcj_moz> ... We don't really have precedents
18:53:20 <jcj_moz> rbarnes: I seem to recall passwords that were wrapped internally
18:53:40 <Rolf> q+
18:53:48 <jcj_moz> ... There's a difference in capabilites and create time vs use time
18:54:26 <jcj_moz> mkwst: You don't really have to squeeze that hard to make this look like the same thing
18:54:29 <wseltzer> ack Rolf
18:54:35 <jcj_moz> Rolf: Assume we go down this path
18:54:37 <gmandyam> q+
18:54:57 <jcj_moz> ... We'd have to put our new credential on the same layer as SiteBoundCredential
18:55:03 <jcj_moz> ... Scoped and Site-Bound credentials sound so similar
18:55:27 <jcj_moz> mkwst: Site-Bound is an artificial construct, and there's no use anywhere in the wild
18:55:43 <jcj_moz> ... All the mechanisms return a specific type, so it should be relatively straightforward to rename it
18:55:57 <jcj_moz> ... Also possible to remove it entirely
18:56:28 <jcj_moz> ... I'm not overly concerned about the tree structure we're creating. What's important to me is that if we call these things Credentials that they all inherit from something
18:56:48 <jcj_moz> Rolf: Just to confirm, for you the credential is not the thing that remains the same over time, but something you send off to the server
18:57:01 <jcj_moz> mkwst: I think that's how the developer using this API would think about it
18:57:10 <jcj_moz> ... I think treating those the same way in the API makes a lot of sense
18:57:30 <jcj_moz> Rolf: That'd be a substantial change to our document
18:57:31 <rbarnes> q?
18:58:19 <jcj_moz> jeffh: We don't have any one thing we call a Credential, we're careful about that
19:03:12 <jcj_moz> rbarnes: mkwst would you be able to produce a PR?
19:03:17 <jcj_moz> mkwst: I'll delegate to dominic
19:03:26 <weiler> zakim, list participants
19:03:26 <Zakim> As of this point the attendees have been jcj_moz, weiler, mkwst, vgb, gmandyam, wseltzer, jeffh, rbarnes, jfontana, rolf, christiaan, angelo, dirk, alexei, alexei-goog, Dominic,
19:03:29 <Zakim> ... Ketan, selfissued
19:03:33 <weiler> RRSAgent, generate minutes
19:03:33 <RRSAgent> I have made the request to generate http://www.w3.org/2017/03/08-webauthn-minutes.html weiler
21:26:48 <Zakim> Zakim has left #webauthn