Web Authentication Working Group Teleconference -- 08 Mar 2017

<scribe> scribenick: jcj_moz

<vgb> is ti just me or is this the quietest party ever?

<wseltzer> Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2017Mar/0126.html

rbarnes: We've 4 open PRs on the agenda
... begin with #312

<wseltzer> https://github.com/w3c/webauthn/pull/344

jeffh: (my opinion) is all expressed in there

<vgb> ah, had to hang up and reconnect to start getting audio

jcj_moz: I've been bad

jeffh: I'd go with CollectedClientPartyData and RelyingPartyUserInfo and be done

rbarnes: See if Kim is ...

jeffh: It's a really minor item, we'll resolve it

<wseltzer> https://github.com/w3c/webauthn/pull/348

rbarnes: OK, on to #348

Angelo: I've got a change to make that I haven't pushed up yet.

rbarnes: OK, on to #350

<wseltzer> https://github.com/w3c/webauthn/pull/350

Angelo: That's me, too, same situation, I've been busy on another feature.

rbarnes: You've a fix on your plate and you still need to fix it?

Angelo: Yes. It's a change on MakeCredential that needs to be merged
... I'm making changes to #350 right now

jeffh: You'll want to merge from master into your branch Angelo

rbarnes: Are these going to conflict with #344?

jeffh: I wouldn't worry about that
... 350 was not controversial ,but 348 may be

rbarnes: jeffh, do we need another round of review on 348 before it merges?

jeffh: Yes.

rbarnes: And you're ok with Angelo merging 350 when he's done?

jeffh: I have some comments on it but yes

<wseltzer> https://github.com/w3c/webauthn/pull/371

rbarnes: On to #371, jeff?

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
... 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
... Some of those issues have already been fixed by this PR and prior PRs
... 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

rbarnes: So that's all for PRs; going back and for reviewing....
... Angelo's going to update 348/350 soon, but 350 can go ahead and land
... and Jeff is still workingon 371
... That concludes Agendum #2.

<rbarnes> https://github.com/w3c/webauthn/issues?q=is%3Aopen+is%3Aissue+milestone%3AWD-05

rbarnes: Agenda #3 is establishing our schedule for WD-05
... Do we want to try and triage some of those here?

jeffh: Which are you talking about?

rbarnes: See link

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
... mkwst will try and join next week

mkwst: I'm on the line.
... Dominic and I are both on the call.

Angelo: Is Dirk here?

rbarnes: It looks like Dirk is here.

Dirk: We're here.

rbarnes: Angelo, mkwst do you guys want to take this away?

Angelo: I'm more of a messenger to mkwst, Dirk can you take it?

Dirk: Where we are currently, is that we want to move our namespace under navigator.credential.crypto and leave everything else as-is
... and that we think that would be a good idea for CredMan to move under navigator.credential.bearer and leave everything else
... that's where we landed from the discussion in WebAuthn

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
... For the credential type you care about - ScopedCredential - could instead inherit from Credential, but not inherit from CredMan's SiteBoundCredential
... 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
... Also in my opinion, at a very high level, the APIs are very similar
... 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
... <description of how CredMan handles passwords>
... <description of how CredMan handles federated credentials and handing auth tokens over to websites>
... 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
... 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
... it seems to be possible to merge those, which is Dirk's option-C in the face-to-face meeting

<rbarnes> mkwst: link to straw-man?

mkwst: I put together a very straw-man-y suggestion a long time ago that has this in it
... 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. ..
... The straw man I posted I think is a pretty reasonable way to look at these APIs
... We can re-use the APIs from the Credential Management
... First we create a new Credential object, AwesomeNewCredential, and we give the prorotype a static registration method, which makes to MakeCredential
... as a developer you'd call AwesomeNewCrednetial.Register and provide similar info as one would for MakeCredential

<rbarnes> https://gist.github.com/mikewest/ca0e488bd4393b08acf9eadfe7092e2e#file-potential-style-js-L39

mkwst: This is slide #5 in the deck I posted
... 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
... so when you all call GetAssertion, you end up creating an assertion that is returned to the developer , and a credential property
... 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
... (Slide 7 by the way)
... 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
... which you can pass up to the server to authenticate
... It's a respelling, and makes GetAssertion into a special case of the Get method
... It doesn't account for the other two methods in CredMan - Store and GetUserRemediation. GetUserRemediation are no-ops for your credential types
... Store is ... (slide 8)
... The idea behind Store might be controversial, but you could use Store to keep data that would be helpful for the user agent
... 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
... Because we'd store that information, that would give us some options in the future that we don't have today

rbarnes: Could you comment on what the store/get would be doing in this API?

mkwst: Store allows us to teach the user agent that the user has an account on this website on this origin with this metadata
... (This could make it possible for the UA to remember what tokens you're using)

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.

mkwst: Yes

Dirk: The two types of cryptographic assertions you get are different
... During registration you get a public key, and during authentication you get something different

mkwst: As far as the IDL is concerned, I believe the two types are quite similar
... The response type from makeCredential has the same attributes as that which comes from getAssertion. Have I misinterpreted that?

Dirk: There was a concrete proposal to make those look the same in the API and make the RP treat them differently

Dominic: Boris brought that up.

Dirk: What is a Credential, the key pair that is assigned to the user, or an assertion signed for the server?

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
... 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

Dirk: When we were discussing at the F2F, one of the things we bumped into when we said there wasn't much overlap --

mkwst: The way (a server) decides if (a Credential) is to be trusted is different for the different types of Credentials
... They are different in nature, but I think the way they are used is similar

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

mkwst: The way the Get method is currently specified is a dictionary of properties that define the credential you care about
... In the dictionary, for passwords there's no filtering. For federations it's already a bit more complicated.
... (Origins of IDPs you trust, protocols, etc)
... I think it's perfectly reasonable to allow the Get mechanism to accept the kinds of information you're requesting
... If that includes a challenge, that seems like a reasonable thing to do
... It's not any more complicated than naming it something else and passing in more information

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?
... CredentialData defined in CredMan has only one entry. Why would you extend that with AwesomeCredential, when we could redefine CredentialData?

mkwst: (These are to be extended by the different Credential Types)

<angelo_> sorry my computer crashed when we started the cred man discussion. Can anyone give me a link to the deck Mike posted?

rbarnes: The thing you're going to pass in to Store here is pretty different than what you get back from Get
... Which is the capability to get signed things, but you Get signed things.
... Is there any precedent for that sort of thing?

mkwst: I agree that it's different. The way that Store works, the most vague part of this pretty vague straw man

<angelo_> Thank you for the link. I have a hard stop at 10:50.

mkwst: What I'm trying to do with that part of the proposal is point to things that might be doable in the future
... (Imagine a web where the website can delegate all auth to the UA)
... (Imagine making second factors look the same on all websites)
... The thing I get back from Registration is different than what you get back from GetAssertion. What we care about storing is the identifier.
... We want to point to this particular Key on the token, and storing that seems reasonable
... but I agree that storing the Assertion makes no sense, storing the metadata seems reasonable
... We don't really have precedents

rbarnes: I seem to recall passwords that were wrapped internally
... There's a difference in capabilites and create time vs use time

mkwst: You don't really have to squeeze that hard to make this look like the same thing

Rolf: Assume we go down this path
... We'd have to put our new credential on the same layer as SiteBoundCredential
... Scoped and Site-Bound credentials sound so similar

mkwst: Site-Bound is an artificial construct, and there's no use anywhere in the wild
... All the mechanisms return a specific type, so it should be relatively straightforward to rename it
... Also possible to remove it entirely
... 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

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

mkwst: I think that's how the developer using this API would think about it
... I think treating those the same way in the API makes a lot of sense

Rolf: That'd be a substantial change to our document

jeffh: We don't have any one thing we call a Credential, we're careful about that

rbarnes: mkwst would you be able to produce a PR?

mkwst: I'll delegate to dominic

- DRAFT -

Web Authentication Working Group Teleconference

08 Mar 2017

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output