W3C

- DRAFT -

SV_MEETING_TITLE

06 Feb 2019

Attendees

Present
agl, jeffh, akshay, emil, JamesBarclay, jfontana, KenEbert, selfissued, NickSteele, PLH, RaeHayward, nadalin, ShaneWeeden, weiler, elundberg, christiaan, jbradley, KenBuchanan
Regrets
Chair
nadalin, jfontana
Scribe
jfontana

Contents


test

<weiler> scribenick: jfontana

tony: start off with status of recommendation
... turn it over to PLH

PLH: IF your AC rep has not responded to the review, please do.
... only 4 respones so far
... not alarming but needs to pickup
... account team asking for members to participate in announcement

tony: i checked with our rep.
... nothing has come through.

PLH: I see some more coming in
... reach out to me.

<weiler> who is Ken Buchanan?

PLH: anything to add to spec

jeffH: we have issues marked with rec
... update my affiliation on the cover page would be good.
... three are three editorial things that need to be resolved.

<weiler> https://github.com/w3c/webauthn/issues?q=is%3Aopen+is%3Aissue+milestone%3AREC

jeffH: we can punt two of them. but need to do hardoced references #797
... that makes sure spec points to right things
... on HTML references I need ot look at those again.
... #1137 I wold like to have done. I will open a PR.

elundberg: #797 I willl look at that

plh: did we make any merge into Level 2

jeffH: no changes to repo

pjl: if you want to merge to 2, use V1 branch

jeffH: lets stay with calling it Level 1
... we will use master branch as editor's draft and it will eventually bump to Level 2
... I can do that.

Agreement

elundberg: closed #797

jeffH: on #996, we decided we can let it ride.
... that is html referecnes, if fine, leave it alone

plh: yes, the message I got was keep it on

JeffH: level 1 Rec

plh: do that, but don't forget to create the branch
... bikeshed understands level, so use that system

jeffH: current is tagged with level 1. I will submit issues to create a level 2 editors draft
... editors draft will become level 2 working draft.
... make level 1 branch today

christiaan: that sounds great.

plh: one more question
... there will be a level 2, anytihgn we can message about level 2. What is next in terms of featres.

<weiler> https://github.com/w3c/webauthn/issues?q=is%3Aopen+is%3Aissue+milestone%3AL2-WD-00

jeffH: one thing. an idea , we have bunch o fissues and PRs that are marked level2. Look at those and see what you think is interesting and let us know.
... we are suppose to go through some of them on the call today.

tony: OK. that takes us to next agenda item.
... i posted notice last week or the week before. face to face week of march 4
... two possible dates. they are during RSA conference. Google will host on the 7th

christiaan: we have space reserved. It will be on Thursday. 10am - 5pm.
... can we get a count.

<nsteele> +present

christiaan: I might send out an email and
... get lunch at Google.
... any conflicts.....nothing
... I will send out the invite.

plh: that is great, it is on the homepage of W3C.
... do we need page for the logistics.

tony: yes
... any other discussion on face to face. it will be a kickoff for Level 2
... not hearing any discussion on face to face.
... go to issues. and look at PRs outstanding for level 2
... do we want to leave the other recs there. we still have consistent terms ....these are ongoing.

jeffH: in terms of rec milestones, the ongong ones update milestone to level 2

tony: #1137 is the only one that looks outstanding. JefH affiliation
... the others go to level 2

jeffH: sure.

tony: we also have some PR to look at for Level 2 to get ready for the face to face. we have 21 outstanding.
... we hanv #1144 that might be a breaking change.
... can you explain #1144 PR

elundberg: from RP perspective, if you want to be certain about things. there are corner cases in the level 1 case. setting APPID may have issues and cause false positive
... if RP sees true output it needs to know if level 1 or 2l client
... with this change, all that happens is appID true means you check...

selfissue: you are still making changes that are a braking change.

elundberg: the client sets the output before it gets ?? from authenticator.
... the client would see u2f authenticator and it should return true, but if they touch the web authN authenticator...

selfissue: i think the right thing to do is fix the normative text.
... on elve 2
... that is actually what I proposed in #1143, it fixes the normative language in Level 2
... #1144 goes a step further. in the end, because there is this busted procedure, to be compatible you need to know two clients exist

akshay: there return does not really matter. ... I would go for fixing the text instead of changing the value

elundberg: i thought this would be controversial, so this is okay

selfisseu: elundberg can you close #114

elundberg: yes.

tony: I think that is the only breaking change, maybe one other issue, or issues that we should discuss for level 2
... we have 4-5 of them, one has been open for awhile #889

JeffH: think we want to do this. there is a PR open. connected to issue #889

christiaan: hope this will get merged when we go to level 2. It has been approved by multiple people
... we did this is in CTAP at FIDO

jeffH: this raises point, we should go through issues and PR and see what is breaking and what is not. don't do it on the calll but keep your eyes open

christiaan: it wont break implementaion..

elundberg: it will influence clients

tony: it is breaking

agl: what is normal definition of "breaking"

tony: any code changes is what we described, should be say breaking clients, breaking authenticators

jeffh: should we not use these terms

jbradley: if something isn't changed will a component really break?

<jeffh> I meant that we should perhaps refine our terms

jbradley: would it be ignored if you didn't do something?

agk: I am happy with any terminology

tony: we also have #991. I think Shane is on the call.

https://github.com/w3c/webauthn/issues/991

agl: this is something christiaan will want as well.

Chare: this is pretty simple. it's about registration, is it represented by a ??? credential?

agl: we have the same thoughts. we don't have a PR yet.

jeffH: I will craft such a PR
... it is done.

Akshay: I think it is an enhancement where we can do both. I think it is fine.
... all authenticators might not support, so I think it is a good idea.

tony: we have #1004

https://github.com/w3c/webauthn/issues?page=2&q=is%3Aopen+is%3Aissue+milestone%3AL2-WD-00

jeffh: we will try to fix it in CredMan

agl: we will not rename any fields in level 2. that is what I think is breaking

akshay: any thing other than public key... any other types

jeffh: I don't understand

akshay: all credentials have a type, it goes to CTAP and authenticator receives this . Question is do we add more key types in futre

jeffH: yes.
... it is more assertion type. for UAF yes.

agl: there is a password type in CredMan, also federate

christiaan: we have been discussing how we consolidate these things
... it is getting hard and weird. how should this be represented to a user
... how do we expose so this makes sense.

jeffH: agreed

akshay: agreed

jeffH: #1044

tony: https://github.com/w3c/webauthn/issues/1044

agl: this is regarding the generic transform an extension from JS objects into CBOR. i am not too worried about it
... this issue is noting some ambiguities in that transform.

elundberg: we are interested in experimenting with extensions that require the translation feature

agl: there are some other things to consider in doing this.
... they type of the cbor could change based on the value inputed
... we could do and not have a breaking change

jeffH: we don't have issue precisely

agl: I will write a comment in here now.

jeffH: also #1060

https://github.com/w3c/webauthn/issues/1060

JeffH: this is related to that modest hairball we are working on to require resident credentials. perhaps address this one PR

tony: since you are writing it can you pull it togehter.
... that takes us through the ones tagged as breaking
... can people go through these. I would appreciate.
... I would like to start a topic discussion for the face to face.
... level 2 is planned out to Oct. timeframe. I thnk that is when our charter runs out
... what do we do. proceed as normal or address it now.

plh: if we are going to revise, we can and say we are working on level 2
... we should worry about this is mid june. we should have a draft.

tony: OK
... anything else for today's call?

<ken> leave

adjorn

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/02/06 18:54:36 $

Scribe.perl diagnostic output

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

Present: agl jeffh akshay emil JamesBarclay jfontana KenEbert selfissued NickSteele PLH RaeHayward nadalin ShaneWeeden weiler elundberg christiaan jbradley KenBuchanan
Found ScribeNick: jfontana
Inferring Scribes: jfontana

WARNING: No "Topic:" lines found.


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


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