test
I can scribe
https://github.com/w3c/webauthn/pull/966
akshay: I think it is editorial
selfissue: it says what implementations need to do
tony: I am concerned about should or must
... if we push this off and it says we have to do soem verification that is a change
rolf: I think it is a change.
... formerly by not change TPM, the RP msy need to add one step in verification
akshay: they were already suppose to do that.
rolf: bit it is not doing that
skshay: Ok
jeffH: clarifying what implementers need to do
akshay: we can mark it for next version
tony: OK. but difference between punting to L2
aksahy: I would punt
tony: any other comment
elundberg: jefH and I seem do agree we don't want to do all that is in this PR
akshay: anything today we be considered normative. I was going to look at this.
... from processs perspective, let's punt to V2
tony: OK
... lets move to V2 / level 2
selfissue: is there an issue related to this we should also move
tony: seems to also be #950
... attestation validation issue
#929 should be marked version 2
https://github.com/w3c/webauthn/pull/970
tony: jeffH is working on
go to PR
elundberg: purely editorial
tony: anyone else want to review? before merge
selfissue: was was HTML spec changed here
jeffH: that is latest html spec
selfissue: looks fine. I will approve
tony: merge. yes
https://github.com/w3c/webauthn/pull/906
tony: jeff had comments
... I don't think it is quite ready yet
... adam added some stuff
jeffH: i am still looking at that
... I need to re-review
https://github.com/w3c/webauthn/pull/951
jeffH: so it sounds like. was hoping somone would say hygiene was oK. Peter agrees we should add some guidance. Draw a clearer boundary.
... lokk at #593 issue, says FFox is not displaying those things because of these potential issues.
... so I could see argument on both sides for this to be level 1 or punting to L2
... from spec quality perspective, I would put it in. it is a couple of shoulds
... text for boundary and overflow is not written, but it is probably one sentence using language JC_Jones suggests
tony: we probably have about 20 days to meet our deadline.
jeffH: what do you mean take it on?
... it is one sentence
tony: we have 20 days to determine...if no one finishes this pulll request it wil get moved to level 2
jeffH: it will get finished? yes.
toy: in 20 days.
jeffH: sure.
https://github.com/w3c/webauthn/pull/956
elundberg: I asked for some...been through most of review. thinking about keeping the figure in here or not. it is not very intersting
... some comments on merging this , jeff? I don't know what to do about this
jeffH: neither do I
elundberg: oh, i just discovered your write up.
jeffH: use case discussion is an interesting one. don't merge until we are all on the same page.
... chrisitiaan has some comments in #334
... I can comment on it in the issue.
... write up I sent to you were my personal notes.
elundberg: what parts do we keep, which to punt
jeffH: maybe I can comment on that
... there is more work to do on this one. all editorial.
... clarify it all in the spec
https://github.com/w3c/webauthn/pull/961
jeffH: lets merge
selfissue: I am looking
... I will merge
https://github.com/w3c/webauthn/pull/962
tony: looking for google input
<jeffh> see elundberg's comment here: https://github.com/w3c/webauthn/pull/962#issuecomment-400394507
elundberg: we might want to use idff error type than I sugested here. make it a recognizable error condition
akshay: in cases where the error is not allowed, you are saying return diff error
elundberg: no saying return a diff error type not allowed error.
... client may ask for consent and return error early. in that caes it is not allowed error. It should be dirfferent error
akshay: do we want this error condition to be distinguished from others.
... I should be around to return early. discernable error
discernible error
elundberg: christiaan can you take a look and make sure what we are asking for.
chrisiaan: yes, I willl look
https://github.com/w3c/webauthn/pull/967
tohy: ready
jeffH: selfissue should look at ti
it
tony: OK
selfissue: it is ready to go, JeffH can merge
https://github.com/w3c/webauthn/pull/970
elundberg: it is already merged
https://github.com/w3c/webauthn/pull/971
jefH: good to get browser folk to review
... do we have a mozilla person lined up while jc_jones is out
tony: no.
... we are trying to get them added to working group.
jefH: I think I did all the technical issues that I was assigned.
... only techical one is #750. I have questions on that one.
... I have a pile of editorial one. my question is on those. PR for each one, or a big honnking editorial with separate commits
slfissue: I would rather have separate PRs. If one is held up it will not hold up the others
jeffH: I knew you would say that.
... looks like 5 issues open
<jeffh> technical issues for PropRec remaining open: https://github.com/w3c/webauthn/issues?q=is%3Aopen+is%3Aissue+milestone%3APropRec+label%3Atype%3Atechnical
tony: what is first technical issue
jeffH: #364
... two of the five have PRs open
#621
this was assigned to akshay
https://github.com/w3c/webauthn/pull/971
scratch that
#621
https://github.com/w3c/webauthn/issues/621
akshay: I will look
https://github.com/w3c/webauthn/issues/712
jeffH: I have been working on this. may punt to L2
... this is low level detail stuff because we have implementations that work
... can we punt to L2
tony: ok
jeffH: not super high priority. I toss the ball back to browser experts. WebIDL experts to.
tony: OK.
jeffH: I don't know if #750 would block going to recommendation or not, might be something to check into
... it is kind of a hairball. with IDL credential management , web authN and media specs that eventually needs to get worked out
... likely need a judgment call on that.
... see what Boris says.
tony: that leaves us with last one.
https://github.com/w3c/webauthn/issues/953
jeffH: a PR is already open.
tony: how many editorial assignments do you have jeffH
elungberg: let me know if you want help
jeffH: 19
... we can make judgment calls on what we need to fix. a lot are fairly simple.
... make a judgment on what to publish
... but many are not calling people angst.
... #462 #358
... emil look at these
elundberg: rate limiting is now defined.
... I will take a look
christiaan: can we go back to #962. we can leave it to the end
tony: we are near end. jump to it now
<jeffh> https://github.com/w3c/webauthn/pull/962
christiaan: why we doing this
elundberg: one is symmetry
christiaan: ok that answers the first. consent issue. are these two statements additive in the sense, if I want to return error I have to ask the user. We are returning the error
... is that complaint with what is written here.
?
elundberg: thinking was, necessary to ask for consent as to not like information
christiaan: user has not cause of action . they will not have a button to not return the error
... I want the RP to have change to do something with the erro
error
scribe: this is like what we did with internal authenticators
... the RP then has change to recover from error
akshay: I understand. you have to return error. you may want to have something for user
... the other thing. how your APIs work with error, if you click you return something.
elundberg: I am worried about . can RP send quest ....is it possible the client could return an error without asking user to proceed with operation.
christiaan: yes.
... the idea is we return error to RP and notify the error.
elundberg: if that is possible, then the RP can ID the user without the user consenting.
... I am saying in this case, the user will be asked for consent. If in this case, the error is returned immediately...that would tell the RP that the credentials are not present. then the RP can ID the user.
chrisitaan: perhaps we wait for use to click the box.
... I don't want to give option to return nothing.
elundberg: makes sense I think this is probably OK.
akshay. Is there a condition where we say user does not want to say this to RP
christiaan: it might be hard to build a flow.
... this might cause problems down the line. we are trying to avoid a small issue.
elundberg: I think this makes sense, I will update the PR.
... hold on for updating PR
akshay: yes.
elundberg: I will expect comment in the PR.
tony: that wraps this up for today.
<RRSAgent> I have made the request to generate https://www.w3.org/2018/05/02-webauthn-minutes.html
<scribe> chair: fontana
trackbot, end meeting