See also: IRC log
Let's start from 397
<wseltzer> https://github.com/w3c/webauthn/pull/397
Alexei is ok with merging it without further changes
J.C. and Jeff would like some editorial changes to be done
MikeW will change the text according to what Jeff wants and then Mike will merge it.
That last comment was for 397
For 398, Mike will make editorial changes today and will merge.
For 399, Jeff is fine with the overall idea but would like some small changes
We are looking through every comment on 399 and address each one.
The decision is we will keep ScopedCredentialEntity what it is today.
<jeffh> ...and modify the algorithm accordingly, yes?
mikew?
<jeffh> we were discussing: https://github.com/w3c/webauthn/pull/399#discussion_r111592611
<jeffh> now discussing: https://github.com/w3c/webauthn/pull/399/files#r111592125
<jeffh> and https://github.com/w3c/webauthn/pull/399/files#r111597596
<jeffh> vgb: just delete line #803 ?
<jeffh> jeffh: ok with me
We will delete line 803 and leave line 872 as it is
<jeffh> vgb: ok, so once we merge these 3 PRs 397398,399 -- we still have the big issues in pr#384
After we merge the 3 PRs, we can start discussing the navigator.credentials
<jeffh> alexei-goog: ok, want to methodically analyze #384, submit issues on each item, and then figure out if we can address them
<jeffh> jyasskin: wrt an issue we might leave open, eg whether an rp can call makeCred asking for any credenail type -- we could leave that for Level 2 spec
<jeffh> angelo: so the question is do we want to make the change of hanging off the Credential object in the CredMan spec...?
<jeffh> alexei-goog: not comfortable that we can pick and choose from the issues they will enumerate in #384....
<jeffh> alexei-goog: is working on doing the enumeration -- did one this morning, try to get done by next Wed
Alexei proposed we he would make issues and enumerate through all of them.
<jeffh> mkwst: am comfrotable to wait on folks being ok with this -- so want to discuss concrete discrete issues with the pr#384 -- so identifying things we agree on and do not agree on is helpful way to go
<mkwst> dialing back in, sorry,hangouts dies.
<jeffh> mkwst: suggest GOOG folk do this because they have firm disagreements wiht pr#384 and best they identify them
<jeffh> jyasskin: what is timeframe MSFT has?
<jeffh> angelo: uh...now
<jeffh> angelo: wants to do nominal merge that is in #384 and just do it and polish later -- right thing to do in longer term -- can clean it up later...
<jeffh> alexei-goog: well, you are going to get more than u want if you just do that merge and it will is not clear what that will mean given discussion s on the list...
Sorry I missed out on the scribe
<jeffh> mkwst: those two funcs are no-ops in the resultant specs
from the microsoft perspective, we just want two core methods that can get user authenticated.
<jeffh> mkwst: requireusermediation() and store() are no-ops for scoped nee publickey creds
<jeffh> angelo: arguing for we obtain navigator.credential.create() and ? -- do that and then deal with details later
<jeffh> angelo: need to do at least that now (in his perspective)
<jeffh> tonyn: you are ok with ... not bing in the implementor's draft? ie wd-05
We okay with not making requireUserMediation, store, isPlatformAuthenticatorReady, cancel method part of the implementer's draft
<jeffh> mkwst: can you make a concrete proposal on this?
<jeffh> vgb: -- can you write that into the notes here please?
<jeffh> vgb: angelo, is that what you have in mind?
<jeffh> angelo: yes
<jeffh> mkwst: is this change to #384?
<jeffh> vgb: yes, tho is more or less going down same path that #384 began
Vijay: one proposal is the eventual result: navigator.authentication.makeCredential -> navigator.credentials.make, navigator.authentication.getAssertion -> navigator.credentials.get
The rest of the methods are no-op
<vgb> Clarifying: requireUserMediation and store are defined but no-op, isPlatformAuthenticatorReady and cancel are just not there (though can be added as static methods later)
<jeffh> mkwst & dirk: <discuss some details, think that it is in list discussion with jyasskin>
<jeffh> angelo: will make new PR that clarifies all this
<jeffh> dirk: why is not store a static method on sitebound....
One way to express the thought is we can make a new PR that makes the changes we just requested. Another way to express that is we can change the existing 384
<jeffh> mkwst: the api is opinionated: it believes the UA mediates the conv btwn user and RP -- for pswds this is clear -- for fed it is clear -- for PK creds, there is use case for store() -- but we do not agree on that -- so generally speaking those apis are there as part of nav.cred because thats the way the other creds wwork -- but if we agree that they are noops for PK /scoped creds, am fine with them being noops at moment, but not forever -- hope this is helpful
We will take the first approach
<jeffh> jyasskin: would store() have func for scoped/pk creds?
<jeffh> dirk: question is how make API less confusing for dvlprs....
<jeffh> jyasskin: say u have sec key roaming btwn systems, reg on one system, then use in another system, if it had been passed to store() in first case, then the UA could know about it in 2nd case
<jeffh> mkwst: knowing that things were successful in past can be useful for UA & RP
<jeffh> dirk: need to thinkabout this, may be something analogous in U2F
<jeffh> angelo: using TPMs, priv key does not leave them, thus this roaming approach not applicable in their case (evthing based on TPMs)
<jeffh> angelo: sees benefits for RPs to get some benefit in near term from the basic merged API
<jeffh> dirk: trying to see benefit to dvlprs having just one method to call to get creds of any type --- but concerned that getting diff creds via same method and then some other methods are noops depending on cred types -- wondering which is more confusing for dvlprs?
<jeffh> dirk: is anyone else concerned about this?
<jeffh> jeffh: all kinds of creds are used in registration ceremonies and authn ceremonies -- more that we can abstract this to enable that such that client-side dvlpr does not have to care cred types the better adoption curve we're going to have
<jeffh> vgb: what if we rename the methods to be something like yayItWorked() and ImOughtaHere() -- would that make things better for developers?
<jeffh> alexei-goog: are you asking were we really wrong that we created makeCred() and getAssn() ?
<vgb> i think alexei was really saying - were we wrong to leave out yayItWorked and imOutaHere when we created makeCred and getAssn
<jeffh> jcj_moz: no we weren't wrong, but up-leveling this stuff to allow the UA to better mediate UX and helps us to add more functionality under the hood down the road (paraphrased heavily)
<jeffh> jcj_moz: (ought to try to learn from expr of federation ) so maybe we do the high level change now
<jeffh> angelo: need to ship, so will likely go with guts of #384...
<jeffh> vgb: clarifys that store() -> yayItWorked(), and requireUserMediation() -> imOughtaHere()
jeffh: the large RPs will have more head space to do a large of amount of identity things. But for the long tail end of RPs which don't have that head space, they don't have the head space to care about that. If we really want to make password go away, we need to make things really easy for those small RPs
Dirk; I guess since I live in the large RP world, I have a hard time imagining how a small website would just not care. But I guess once they make it to the server side, the difficulty will arise
jeffh: but there are libraries that will make that easy for developers
tony: I'd like to understand what the problems are.
JC: At firefox, what we are holding on to is the namespace
<jeffh> jcj_moz & angelo: getting namespaces and method structures figured out soon is priority
<jeffh> mkwst: for blink it is easy to handle webidl changes....
mikew: we agreed we will make changes to the PR later today and merge them.
Dirk: we are ok with merging it in.
<jeffh> dirk: ok with merging in, in order to get the namespaces nailed down, and deal wtih problems afterwards
All of us are ok with the namespace change.
<jcj_moz> metaphorical beer
<wseltzer> [adjourned]
<wseltzer> scribenick: angelo
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Default Present: vgb, wseltzer, jcj_moz, dominic, nadalin, mkwst, jeffh, battre, jyasskin, dirk, alexei, apowers, alexei-goog, angelo, selfissued Present: vgb wseltzer jcj_moz dominic nadalin mkwst jeffh battre jyasskin dirk alexei apowers alexei-goog angelo selfissued Found ScribeNick: angelo WARNING: No scribe lines found matching ScribeNick pattern: <angelo> ... Inferring Scribes: angelo WARNING: No "Topic:" lines found. Got date from IRC log name: 14 Apr 2017 Guessing minutes URL: http://www.w3.org/2017/04/14-webauthn-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]