Web Authn WG meeting -- 16 Mar 2016

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

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

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

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.

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

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: 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?

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

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?

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

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

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

<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

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

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

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

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

Next f2f

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

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> hhalpin: meeting time is 1pm Eastern time; US is currently in Daylight Savings

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

Summary of Action Items

Summary of Resolutions

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]

- DRAFT -

Web Authn Working Group meeting

16 Mar 2016

Attendees

Contents

roll call