Web Authn Working Group meeting

16 Mar 2016

See also: IRC log


jcj_moz, felipe_bbg, hhalpin, wseltzer, dirkbalfanz, juanlang, alexei_goog, samsrinivas, nadalin, vgb, axel, Adam, Powers


chair: Tony

scribe: hhalpin

roll call

Note I've sent the email out to the mailing list.

Status of items agreed at F2F

Tony: JeffH will likely not be here
... he populated the status of the items from the f2f
... it was populated as of yesterday

Here's the open issues from JeffH: https://github.com/w3c/webauthn/issues

Tony: We can go through the status of them
... although I believe no new work has started
... we can go onto document merge update

Document merge update

dirkbalfanz: JeffH started by converting to bikeshed
... isn't really that much of a change
... basically concated them with a few exceptions
... in the signature docs all the explanations of how the extensions work
... not just for the signatures, but for everything
... so that was moved into its own doc (i.e. out of middle of the signature) and into boilerplate
... and when there was a sentence it has an intro, boilerplate
... so there's one big session with the API, then a section on signature format, and then a format on the attestation bits
... and then there's a section on extensions
... JeffH thinks its fine
... so now we delete the three separate subdocuments

Tony: Normative text was not lost?

dirkbalfanz: No, I changed things only in terms of cross-references and making sure the normative references were all correct

<jcj_moz> I did a review as well; I'm not 100% through the merge - about 80% by line count - but so far I haven't found anything unexpected

dirkbalfanz: so I changed some paragraphs, conformance etc.
... so we changed conformance to be a union of conformance of the older 3 docs

rbarnes: Its' in doc-merge?

dirk: Yes, and since the older sources are still there
... its easy to see what happened
... so if you go through Respec source to bikeshed source, you can see what the changes are
... for example I didn't change line-breaks, diff should be pretty clean
... I think we can get rid of 3 docs and start working on merged documents

rbarnes: Let's have 2-3 people review after pull request for merged doc, do a second pull request to delete 3 original subdirs.

dirkbalfanz: Yes
... I did them both
... but make sense to separate

<rbarnes> https://github.com/w3c/webauthn/tree/doc-merge

vgb: Where should I look?

dirkbalfanz: See doc-merge

Tony: Issues on status of the merge so far?
... Create the pull request after the meeting

Dirk: Getting an error, PR error

wseltzer: Issue that we need to enroll you
... will fix it

Note I'm seeing Dirk Balfanz as 'part of W3C' organization...hmmm

dirk: Seems error

<dirkbalfanz> Pull request for the merge is here: https://github.com/w3c/webauthn/pull/44

jcj_moz: I can set up Travis

<scribe> ACTION: jcj_moz to set up Travis [recorded in http://www.w3.org/2016/03/16-webauthn-minutes.html#action01]

<trackbot> Sorry, but no Tracker is associated with this channel.

jcj_moz: Will set that up the latter part of the week

tony: Thanks Dirk, that gets us on its way, once the pull is satisfied
... Mike can review the pull request
... I've seen the naming issue come up
... I've not seen any recent issue

vgb: I've not been here last couple days

<rbarnes> we are apparently a very just WG

vgb: so, I feel the question we left out should we aim to produce something and then build in extensibility mechanisms
... so if for example, there's a tweak to signature format, we can incorporate
... a new format
... in the spec, or we can do it via a new enum
... rbarnes supported a new enum
... additional changes in the future if we go that route
... I can't give you an intelligent answer if we go via enum route
... at this point

rbarnes: From a developer's perspective is there's changes a developer can ignore they should not have to change the API
... let's focus on that level of abstraction
... let's not nail down definition of these classes, so that if any attribute gets added
... in an attestation format, then we don't have change the API per se
... as generic as possible but not more generic
... vgb, what extensibility affordances are you worried we need to add?

vgb: One potential thing the various fields in the client hash are y in a particular way, that's not versioned
... suppose we are to change how that stuff is hashed, the API has not changed but the signatures format has versioned
... or if we add UI interaction hint
... from a code perspective you have to add this new parameter
... should we consider that a versioning change
... or on some particular kind of hardware you will just encounter errors?

rbarnes: Opinions?

jcj_moz: When you make that kind of change to hardware it seems it should be different version of spec
... its a new kind of enum

vgb: But it could be functionally identical
... it just needs one parameter that s otherwise optional in spec

rbarnes: So would you need a capability discovery?

vgb: I.e. do we need affordances
... so we need different versions

rbarnes: Can we flag this and punt to move on?
... chose a generic name for the moment?
... when would that change

How about re "native" API implementations? "Web" is generic and liked by W3C, but we don't want developers having to change doc reading if we can get one API that works well between native and Web

rbarnes: We can just use "Web" as a generic

dirkbalfanz: Note vgb has 3 different levels of abstraction, what level are we?

rbarnes: We have these spots called "FIDOCredential"

dirkbalfanz: Generally speaking
... sometimes its the API, but sometimes there's very specific things being referred to
... shall we go through ALL of them and replace FIDO with another placeholder?

rbarnes: Yes, that's right
... so we can replace FIDO2 with something that's functionally descriptive

Tony: We may have to do something where we keep FIDO as a conformance spec
... so it may make sense to keep the term FIDO in certain place
... so we don't want a FIDO-certified credential to be open for interpretation
... so we'll have to keep the name FIDO in some particular values

rbarnes: That may indeed be
... but its fair game tor FIDO to have conformance to a subset
... so we could imagine that being a browser?

Could we give a shot a separating anything FIDO-specific from just the generic use of the term "FIDO"

sampath: Maybe we could go through these and keep a generic placeholder, and see where we need to eventually pass through?

rbarnes: jcj_moz, since your new, could you give this a shot?

jcj_moz: Happy to go for that

<rbarnes> ACTION: jcj_moz to take a pass through the spec and make some recommendations w.r.t. "FIDO" usage [recorded in http://www.w3.org/2016/03/16-webauthn-minutes.html#action02]

<trackbot> Sorry, but no Tracker is associated with this channel.

felipe: Hi, this is Felipe from Bloomberg
... so the question from outside FIDO, are we identifying the format of the signature in this spec
... then we should not have the spec refer to FIDO
... as its an outside spec

<rbarnes> +1 to felipe_bbg, we also own the signature/assertion format

felipe: so its a reference from this to FIDO
... or from FIDO to this

Tony: We need to keep this something developers understand
... developers are already concerned.
... would you be interested in going through the spec and seeing where ugh?it goes thro
... seeing where a generic name goes through?

I'm going to state that we also want to make clear FIDO and W3C are working together, and we need to acknowledge this in the introduction to the document

scribe: and for things that are FIDO certified

<apowers313> yes, FIDO will do certification

scribe: I think it makes sense to keep the name.

<apowers313> we are happy to let W3C reference our trademark, so long as it uses the (R)

Sounds like a question to throw to FIDO how they want their name used?

<wseltzer> wseltzer: Trademark holders need to protect their marks as designations of source

dirk: We don't want to end up in a place where Chrome does WebAuth and Firefox does WebAuth and they don't have interop on authenticators
... are people arguing that for level of genericity?
... RPs should know how to verify that kind of signature

<wseltzer> wseltzer: so they (and we) wouldn't want to put the trademark into a W3C spec where W3C has change control

dirk: rather than another kind

rbarnes: Sounds like right level to me

sampath: We have this use-case we want to work, you use Firefox on Windows
... you register on acme.com your passwordless login using the iphone
... re bluetooth
... something happened
... you got a key register, you should be able to go to Chrome on a Mac
... and login using the *same* iphone
... so the WebAPI semantics should be identical
... so the hop to the iphone
... which is done over FIDO should work

rbarnes; Maybe that's too ambitious

scribe: but at the WebAPI layer we need to make sure the API looks the same across those scenarios
... then the folks that tie together the lower-level stuff can define the right kind of typing
... to make sure those messaging

sampath: Note this is already happening with U2F wrt Firefox and Chrome
... so we should make sure this works

Tony: So inagine tomorrow you wanted to throw out WebAuthn
... how do you distinguish between formats

Everyone who is dialing in, please type "present+ yourname" into IRC

We've had some bad luck re starting our first meeting with DST hits the USA, so I hope we haven't thrown Europeans off too much

vgb: I would like to agree with how Dirk scoped the problem

<dirkbalfanz> That was just me dialing again from another phone.

vgb: so we will have to make sure its got interop
... in theory and in practice
... optional makes it hard
... so lets keep narrow focussed

I'd like to say the question may that we see some authenticators that FIDO does not certify but we want interop with (i.e. 'weak' credentials come to mind)

if that is the case, then it makes senes to keep it generic and use FIDO for the names of credentials that normatively must be FIDO certified

Would be an interesting question for FIDO

<Zakim> wseltzer, you wanted to discuss TM, again

apowers: I don't think they'll be a trademark issue, althogh we can discuss in FIDO

wseltzer: As the lawyer in the room, happy to have this conversation
... but we would probably not want to use a trademark as name of method or API element
... as we don't want to be saying 'the only way to satisfy this is a third-party certification'
... but we can make normative references to FIDO
... so we want to match ways trademarks are normally used

bikeshed vs. respec.js decision

Tony: Anyone have issues with going down the bikshed route?
... not hearing any, we will continue down bikeshed route

<rbarnes> my impression is that bikeshed is what the cool kids are doing


seems to be THE future

Next f2f

<wseltzer> rbarnes: Friday, May 13

Tony: We'll have a one-day meeting at the MS office
... room for about 150

<wseltzer> [in Berlin]

<wseltzer> hhalpin: that's after a 3-day FIDO meeting in Berlin

<wseltzer> ... we'll have a registration

<wseltzer> ... we can encourage people who are considering membership to observe the meeting

<wseltzer> tony: FIDO 2.0 meeting currently scheduled Tuesday (we tried to move it, but couldn't)

<wseltzer> ... WebAuthn scheduled for Friday

Tony: Note Tuesday is the FIDO 2.0 meeting would have to stay an extra 2 days

Given there's no objections to that date, I'll make a registration form.

Open Issues in Github

Tony: JeffH has tried to tag each item
... if people could take a look at the 39 or so issues that are out there
... make sure they are tagged right
... work with JeffH to get the tags in order
... and then we'll go through these issues the next meeting

<wseltzer> hhalpin: if we can go through these issues, get in good shape by F2F, we can push out a FPWD

I'd like to add the F2F's objectives should be to have these issues basically resolved so we can push out a First FPWD

<wseltzer> rbarnes: FPWD is a good objective for F2F

rbarnes: end of the agenda

<wseltzer> hhalpin: meeting time is 1pm Eastern time; US is currently in Daylight Savings

Yep, we'll update the calendar invite

So we have a So have a two week window where there's a 5 hour difference and then back to normal 6 hour difference

So meeting is 6:00 PM CET for 2 weeks, then 7:00 PM CET

trackbot, end meeting

<trackbot> Sorry, but no Tracker is associated with this channel.

Summary of Action Items

[NEW] ACTION: jcj_moz to set up Travis [recorded in http://www.w3.org/2016/03/16-webauthn-minutes.html#action01]
[NEW] ACTION: jcj_moz to take a pass through the spec and make some recommendations w.r.t. "FIDO" usage [recorded in http://www.w3.org/2016/03/16-webauthn-minutes.html#action02]

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/03/16 18:29:07 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/docmerge/doc-merge/
Succeeded: s/has changed/has not changed/
Succeeded: s/to the future//
Found Scribe: hhalpin
Inferring ScribeNick: hhalpin

WARNING: Replacing previous Present list. (Old list: Felipe_Moreno, harry, cbrand, keiji, JeffH, adam_powers, rbarnes, nicolagreco, Vijay, Bharadwaj, Microsoft, alexei_goog, Hubert, A., Le, Van, Gong, PayPal, jcj_moz, Sam)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ jcj_moz, felipe_bbg, hhalpin, wseltzer, dirkbalfanz, juanlang, alexei_goog, samsrinivas, nadalin

Present: jcj_moz felipe_bbg hhalpin wseltzer dirkbalfanz juanlang alexei_goog samsrinivas nadalin vgb axel Adam Powers
Regrets: rbarnes

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Got date from IRC log name: 16 Mar 2016
Guessing minutes URL: http://www.w3.org/2016/03/16-webauthn-minutes.html
People with action items: jcj_moz

[End of scribe.perl diagnostic output]