<weiler> scribenick: jfontana
tony: selfissued signed up to do
IANA Registry
... can we use the same numbers we had. wew did not get an
answer
jeffH: we can reserve our numbers for a year.
sam: hopeful they will give us those numbers.
tony: we have path of resolution
on IANA regisry
... jfontan workign on PR doc . outlining in line with our
work
... extensions. if yo do implement, material in document is
normative. Tath is the goal.
... not sure we will get implementations on all extensions.
this is still work in progress
gmandyam: this debate is gong to
be prolonged, better to do on mailing list
... what will constitute interop of extensions is question.
interop can be determined from examining two browsers in some
case, some cases in hardware
weiler: which ones should be in what categories.
gmandyam: I can write down the different categories of extensions
weiler: I can take those to Ralph
gmandyam: attestation formats
will be weird as well
... not sure that is separated here
... are attestation not candidates for interop. fine with me if
they are.
tony: to some extent the attestation blog and sending to RP, or service, etc., and let them do processing. some RPs will ignore attesation .
gmandyam: that is good way to
look at it. has some precedence
... look at attestation data as opaque
wseltzer: do we have distinction on registry, how it should be done.
gmandyam: we decided on regisry,
but have pre -registered and list in spec. we have lattitude to
do that.
... other registries. registry entrants are listed as
normative
wseltzer: we have slight
different interpretations of word normative.
... there is general policy that every feature in
recommendation, needed multiple implementations, that is issue
putting registry in the document
gmandyam: we did ask about
this.
... we realized this might be an issue.
tony: we might have been pointed in the wrong direction
weiler: why do we care about non-normative.
tony: we don't want implementation to be different than what is documented.
weiler: if it is normative, it doesn't mean users will get it write
tony: we can't police, be we need something to go against that is marked normative and prove how it has been spec'd
gmandyam: FIDO will have a
certification program around this. we do't want to give
implementers an wiggle room
... our certification program may run into issues on that
apower: that is conversation to be had.
weiler: so far I am not sold
tony: this is a very important
issue. we need to get resolved.
... lot of stuff pending on this one.
... not in favor of ignoring. but in favor of taking it to the
list.
... back to agenda.
some PR issues.
https://github.com/w3c/webauthn/pull/821
gmandyam: the text implies an
authenticator is limited to 32 bytes. for UVI hash.
... RP is only required ... for 32 bytes of hash
... we want to future proof this. relax the requirement to 64,
this would future proof this and re-word the server
requirement
... other option is to say any size , up to any limit. that is
ultimate futrue proof
... but may make for a little bit of design flexibility
... I don't like the working in the spec that is why I want to
change
rolf: crypto agility is
relevant
... talking about certification ., servers that want to be
certified, should not ignore some things like UVI
... proposal up to 64 is not a complicated ask
tony: certification test can work
however they want. maybe looking at only first 32 bytes.
... not sure why spec , woudl need to go into any more
detail
rolf: we should make sure that our 32 requirement should at least go verify 32 byts.
ag: 64 bytes is acceptable, we should not go arbitrary
agl:
tony: to me this is more editorial change.
gmandyam: I put in CDDL limit of 64. that's all it is, it is a slight technical change, not allowing UVI to be of undetermined length.
tony: still nothing wrong with
saying that
... and RP can do what it wants.
... tryign to separate out what we wnat ot enforce as FIDO is
concerned. and what we what in th e spec just to happen
rolf: we shold at least say 32 or 64 or some number
tony: we could leave as is. and when FIDO wants to do certification testing we could limit this.
jeffH: it is limited to 32 in the text
gmandyam: don't let RP ignore 32 bytes in 64 string
tony: we could do some editorial work on spec.
rolf: should make sure more than 32 is not prohibited, and in certification we can test against what is require to accept.
tony: any problems.
gmandyam: need some refinement in text
gmandyam will update
https://github.com/w3c/webauthn/pull/825
tony: this has been
approved
... can we merge?
elundberg: it is merged.
https://github.com/w3c/webauthn/pull/826
agl: minor rewording
tony: merge?
jeffH: merged.
https://github.com/w3c/webauthn/pull/827
agl: not quite just rewording. warding people off doing something dubm
jeffH: i need to review
https://github.com/w3c/webauthn/pull/829
elundberg: needs some
review
... wor in progress
jeffH: agl should review
tony: rolf?
jeffH: sure
https://github.com/w3c/webauthn/pull/830
tony: ready to go?
elundberg: jjeffH has sgined off. merged
https://github.com/w3c/webauthn/pull/832
elundberg: editorial cahnges
tony: jeefH will review
jeffH: will take a look
https://github.com/w3c/webauthn/pull/836
tony: neither angelo or mike J
has looked at it.
... would like to have selfissued look at it (mike J)
https://github.com/w3c/webauthn/pull/842
elundberg: work in progress. need more ideas how to do this
tony: add rolf to this
https://github.com/w3c/webauthn/pull/843
tony: this one looks OK to go
JeffH: merge
https://github.com/w3c/webauthn/pull/849
elundberg: basically verification of user presence. I messed it up. This is just fixing up logic
tony: i have added rolf and akshay and jeffH
elundberg: this is
editorial
... more policy than technical
https://github.com/w3c/webauthn/pull/850
<jcj_moz> All: I need to change to a different meeting, sorry!
elundberg: suggest by a reviewer. pointing out assertion verification is compatible with U2F
tony: need Christaan from U2f side to look at this one
agl: looks reasonable to me.
tony: i will add you.
Christiaan: I will look at it
tony: takes us through the
PRs
... one that was just opened. 847. does not have a
milestone
https://github.com/w3c/webauthn/pull/847
jeffH: assigned on the call
tony: can this be merged?
jeffH: need at least one to look at it. JCJones?
tony: assigned to jcj_moz
... down to about 11 PRs, hope to get closed in next week or
so
... some issues for PR
... currently 45 open PR issues
Ibrahiim: I have issue I want to discuss 851
https://github.com/w3c/webauthn/issues/851
Ibrahim: platform key stores, will get wiped. way web authN is currently worded. do we care about this issue in regards to RPs. if we do, what is guidance to prevent this
christaan: we are wrokign on
exact same thing
... should figure out more and should be no prompt for security
key at that point.
... I think our current spec will throw error back to RP. For
privacy that is not such a good idea
... on adroid we know when a key got wiped. so we can be
smarter about it, but not sure each platform has that
information
... wondering if we should not in next version solve this once
and for all.
Ibrahiim: google lets the paltform know key is not there. What do you return.
christiaan: we return
something...
... will check
Ibrahiim: the key begin there you keep a list of registered keys on that device.
christiaaan. yeah. my info. here is hazy.
scribe: I definitely think we should add some thing back here.
Ibrahiim: OK
... can you share...we would like to align with what the
browsers are doing.
christiaan: sure
tony: so christiaan, you will update 851
JeffH: added notes to the issue.
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) Present: jcj_moz weiler nadalin gmandyam elundberg arnar ibrahim JeffH jfontana Rolf wseltzer JBradley apowers akshay agl christiaan Found ScribeNick: jfontana Inferring Scribes: jfontana WARNING: No "Topic:" lines found. Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2018Mar/0186.html Found Date: 28 Mar 2018 People with action items: 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 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]