<jcj_moz> Zakim start meeting
<jcj_moz> Zakim help
<jeffh> jbradley: encouraging platforms look at and consider implementing this extension
<jeffh> ...will look into sharing the "shape" of the needed extension
<jeffh> jcj_moz: moz is intending to implement this
<scribe> agenda: https://lists.w3.org/Archives/Public/public-webauthn/2020Feb/0070.html
<scribe> Meeting: W
<scribe> Meeting: Web Authentication WG
<jeffh> ...thinking that we webauthn/fido need to provide for account recovery, and assuming the security review (to be published) is positive, Moz will implement
jc_moz: once we have it , we can ease a thorny issues around web authn
Ricky: there is reveiw to prove this out - when is deliverable
jc_moz: output would be the proof logic and research paper of that proof
bradley: we should have this in a
month of so.
... after we get this done need to convince RP this is good
thing
... backup authen can be used go get a new credential
... wneh you recover yo can create a new backup.
... we tried to separate the key material and meta data of
where you used it.
jc_moz: spec on RP side is non-trivial
bradley: can enroll a credential without having your backup.
jc_moz: when the paper is
published, that is when the work will start.
... specific to this mechanism.
<jeffh> ...if you have detailed questions, email emil@yubico.com (I think that email addr is correct) aka @emlun on github
ltony: still have caBLE issue in fido land, brings in network transport. any cisco updates
nickS: working on it. we will
have something soon.
... we will move forward with a PR. We are are doing this on
CAble to PR branch
tony: imagine there will be change over in WEg authn land.
nick
nick
nickM: would you prefer an issue with our current intentions.
tony: that works.
... we can track it and get it on our radar.
Arnar: for new caBLE PR there is nothing new.
tony: we should close 909
#909
tony: enterprise attestation
christiaan: we have a PR
... fido says they need two weeks
tony: PR should have answered the
questions.
... discuss on the 4th of march
... thye have had there two weeks
agl: add an entreprise attestation type ?
christiaan: merge it now?
jc_moz: it is still a enum
... we need to un-enum it
... we ran into this with transports
agl: should we touch the enum, where do we create the mess?
tony: it is a breaking change.
jeffH: we have six enum types. we
need to address?
... should we apply to all enums
jc_moz: first we should do enterprise attstation .
agl: transports are special, but browser has to do something. what is the behavior
jc_moz: good question. options
areedefault or error
... are a default or error
jeffH: we should submit an issue to deal with dom strng
agl: we should un-enum some
things - lets take a look at what they are.
... client data serialization
... we serialize with json. proposal value is json but
validators can depend on keys come in specified order...will be
a conical JSON
... we are adding structure.
... it is structure within previous specification
jeffH: it should go through standard JSON parser
dwaite: if anything other than
browser can access, that when someone could try to game
system
... if extension where I can supply data, have to be carefull.
could be client level attestation
... i am worried about some of previous issues with SAML
agl: I have said JSON is not too
hard.
... referring to open SSH
... openSSH has looked at this proposal
... I can work on a PR. aim is to avoid another sub-section in
Level 3
... opinions welcome.
jc_moz: i am in favor of making this easier, JSON can be a heavy lift.
shane: suggest. I did not read PR yet, parsing JSON may be preferred
agl: I will make that clear.
bradley: there are opps. here to inject bad things
dwaite: we will have to careful how we explain this
bradely: we can wind up with something now that might shoot us in the foot later
agl: i should write validator algorithms
dwaite: I think that is
missing.
... we need to be clear with the validation rules.
agl: i understand the
concern.
... the fix fields will never change. we could add more, but
the first 4 won't change
tony: we are saying they are fixed now, but that can change in the future
agl: we are committing to never changing these four fields.
alexei: can we add a version
number.
... when we do version 2 it would break everything.
... everytime we change we break everything.
proposal is client data serialization. Adam will write a PR.
jc_moz: mozilla is opposed to
this.
... we have to make a PR that reverts a handful of changes.
jeffH: will be one policy for get and disallow use of create in cross origin iFrames
bradley: i don't think the
payment people know this is there.
... the payment people don't like the idea of explaining a flag
in a browser.
agl: it is behind a flag so we did not pre-maturely ship things.
tony: jc you will write PR for thils
jc_Moz: think jeffH should but I can help.
jeffH: OK
https://github.com/w3c/webauthn/issues/1303
jc_moz: I agree with the issue
and think we should close it.
... also #1293 is part of that
agl: close great
tony: and do PR for
... #1336
Ricky: our concern is taken care of by the other issue.
jc_moz: I want to make sure Apple is on board
ricky: i am saying this is OK given the feedback.
closing #1303 and opening a PR on #1336
https://github.com/w3c/webauthn/issues/1347
ricky: this needs to be
reconciled with get assertion in conjunction with an
iFrame.
... I need to read this more closely, but need to reconcile
some of what is here.
jc_moz: there are concerns at Moz. we want to build a pattern for Web Authn
agl: I strongly recommend you assume no state.
ricky: where we are, devs should assume no access to local state.
gl: I would like to have examples.
agl:
ricky: directions to devs, i
would say no.
... I don't think it is a spec issue. I think it can be
closed.
tony: jeff will add
comments.
... we are briing uup #1372
https://github.com/w3c/webauthn/issues/1372
shane: reason why I brought it
up, related to scenario that web authn could not implement but
u2f could
... seems to me that RP have a trust relationship does not
necessarily need to have creds registered at each one of
them
... i was trying to implement..
... it doesn't seem the only way should be to register all of
them.
bradley: there are some RPs concerned about it.
tony: with shane's concern. some were thinking about #1372, Dirk did present some things at FIDO plenary. He will show this.
shane: how does Dirk presentation differ from what I am talking about.
tony: payments also brought this up on a call.
Dirk presents propsal
dirk: proposal RP A can create a
credentail for RP B
... what about tracking/correlation?
... RP S cannon exercis the credential aftereward.
... cannot exercise ...
... looking for feedback.
... P
... and to do a PR to webauthn spec
ricky: I think we need more
explanation, where do requirements come from
... UX and re-direct is something I want to understand.
bradley: we are making this case to the PSD2 people in Europe
jc_moz: so the presentation of
the cross-frame credentials is concerning. how do we
communicate this to users.
... this flow can be confusing.
bradley: this does not introduce correlation.
shane: facets idea is not for solving this use case.
agl: this is new form of cross origin communication. I am not the right person to give an opinion.
bradley: you have to do some kind
of federation to do this
... this may be a change for the web authn on platforms
... we ar ea bit vague what web authn is.
dirk: i wil have action items
tony: have it for the web
payments meetings.
... shane last words
shane: issues I have raised are
different from what dirk is working on.
... totally different scenario, chance for confusion if we lump
into same discussion
... I am not against Dirk's proposal. I have a different
scenario.
tony: we want to leave this open for now. there is not a real solution.
shane: if consensus of the
browser vendors is we are not doing facet IDs, that is the
decision.
... I suspect there is good reason behind their ideas.
christiaan: we are moving away
from cross origin.
... it is hard to defend now
shane: thoughts are strong here and they are landing against such a proposal
christiaan: what shane is proposing can be abused.
tony: those aree major issues for
today, but some issues to close.
... #909 caBLE extensions
jeffH: which we are not going to need
break
resume
https://github.com/w3c/webauthn/pull/1366
tony: we will fix enum here. and
#1376 will take care of the other enums.
... agl should updatge
https://github.com/w3c/webauthn/pull/1369
jeffH: looks good to me.
... waiting for reply from Akshay
tony: that takes us through
PRs
... we still have a few issues.
... want to take care of https://github.com/w3c/webauthn/pull/1369
in next RD draft.
... who will take this.
... shane leave #1372 open
shane: want to have something
that says why we are not doing this.
... I don't know the answer
tony: do this one with other cross origin stuff? https://github.com/w3c/webauthn/issues/1377
https://github.com/w3c/webauthn/issues/1358\
jc_moz: i think this is no
action
... I am about to land a bug
jeffH: close this?
jc_moz: it is a bug on firefox, this is closed.
tony: still working on #1207, 1208 1291
#1208, #1292
#1291 not 92
tony: apple not opposed, think we can go adhead and close this on #1292
https://github.com/w3c/webauthn/issues/1292
jeffH: close
https://github.com/w3c/webauthn/issues/1293
jc_moz: interested in this as an idea
tony: update this jc?
... don't close, add a comment.
https://github.com/w3c/webauthn/issues/1304
agL: this is just about what you put in your UI
christiaan: like android can use
many modalities, and have done it without the need for this.
]
... this is pre-cursor to RPs eliminating support for
modalities .
jc_moz: this is going back to RP showing more context
agl: if you are trying to return a name or a string. names can be mis-understood
tony: should we close.
jeffh: I will close it.
https://github.com/w3c/webauthn/issues/1331
tony: we need someone to do
this.
... if we don't do something this willl fall off bucket
https://github.com/w3c/webauthn/issues/1363
agl: lots of words on this. need someone to turn this into something concrete.
tony: somebody should create a PR
agl: add a convenience method.
selfissued: my hygiene to this is you might be introducing duplication and then values that are not the same
jc_Moz: we give back a dictionary.
tony: need a PR
agl: this is editorial thing. I should do this.
Debate on required, preferred, discourage, forbid and use cases.
christiaan: we don't have forbid today, but I want to add it
dirk: there is no need to support this use case
shane: use case is deisgn for targets
agl: if we support all four, everyone will be happy.
jeffH: added this issue after discussion. https://github.com/w3c/webauthn/issues/1379
tony: will work on CTAP 2.0 to consider this issue
dwaite: do we want to do
clean-up
... clean up extensions.
jbradley: I will clean up extensions.
tony: any other topics for today
?
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 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: jcj_moz, jeffh Present: jcj_moz jeffh jfontana jbarclay selfissued nmooney No ScribeNick specified. Guessing ScribeNick: jfontana Inferring Scribes: jfontana Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2020Feb/0070.html WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]