W3C

- DRAFT -

Web Authentication Working Group Teleconference

28 Mar 2018

Agenda

Attendees

Present
jcj_moz, weiler, nadalin, gmandyam, elundberg, arnar, ibrahim, JeffH, jfontana, Rolf, wseltzer, JBradley, apowers, akshay, agl, christiaan
Regrets
Chair
nadalin
Scribe
jfontana

Contents


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

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/03/28 18:00:13 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]