scribe jfontana

<scribe> agenda : PR , TPAC agenda,

<weiler> scribenick: jfontana

tony: anything to add

Christiaan: remmber the PR agl submitted on transport being plumbed through. hoping Akshay can look at this now, it is critical. Just to determine the directon

it's PR 1050

<jeffh> https://github.com/w3c/webauthn/pull/1050

tony: for Pr we canfile as early as Sept 18, that would put us into October for publication.
... that would put is into the end of the year for w3c recommendation.
... move to outstanding PRs
... we have.

emil today

https://github.com/w3c/webauthn/pull/1036

elundberg: waiting for review. Sam has looked at it.

tony: if Mike responds on #19036 and signs off we kcan merge.

https://github.com/w3c/webauthn/pull/1052

tony: looks OK

elundberg: some discussion on PR in parellel which is #1053

selfissued: (now on call) says he can review #1036

jeffH: user handle pair yields on unique credential source.

elundberg: per authenicator

jeffH: if you don't supply exclude credential, you could do it.

elundberg: yes.

jeffH: the user handlel does not need to map directly to match one to one to RP notion of account identifier

elundberg: not necessarily

jeffH: it is up to RP

elundberg: yes, what ar you getting at.
... we can continue this is comments in PR

johh_bradley: it is up to RP to show how credentials map to user accounts.
... in some cases for privacy...but is it up to RP if they use that at all. must it be different for different accounts. am I understanding this?

jeffH: more of less..
... trying to get at an RP map wish to map multiple users handles to a given account to align with their notion of account

selfissued: I have many handles, they are equivalent but they are different handles.

elundberg: I must have misunderstand this PR
... I will take another look.
... I was getting at with my review, it is not necessary to have multiple credentials to have multiple user handles.

jeffh: that violates other things in the spec.

elundberg: i will revise my review of this.

https://github.com/w3c/webauthn/pull/1054

jeffH: I am in middle of review on this.

tony: another for selfissued to review.

selfissued: I will look at it

jeffH: I am still trying to write this up

https://github.com/w3c/webauthn/pull/1055

elundberg: purely editorial

tonly: for selfissued and jeffH to reivew

https://github.com/w3c/webauthn/pull/1057

tony: pure editiorial

elundberg: yes.
... verdict was it is nice to get this into PR, or punt it, so we did it.

tony: issues

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

tony: this one is in the fetch
... also #403, pr opened here - this should get closed when emil updates analysis
... #462 will get done when it is done

#585- PR open for this one.

scribe: #704 editorial
... #733
... think we are OK on.
... Sam have they gotten back to you . accessibility WG

@weiler: nope

tony: even if they hav enot gotten back to us stillin favor of going to PR

@weiler: yup.

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

jeffH: emil did commit and it was OK.
... this is ongoing thing, it is something we need to check at each milestone
... null stuff is done

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

tonu: out of our area

#1014 need to finish review

#1020

scribe: #1022 Arnar was suppose to look at this AGL is working on that.

jeffH: It's clarifications it seems like

tony: some are doing it now. Shane had some issues
... we talked #140, #1045

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

jeffH: this has to do with AppID and Facet
... it would be good for windows folks to point out whats going on, chrome teams and firefox can chime in.

gmandyam: if this is related to mobile apps how can microsoft talk about this is they are not using that platform

tony: I think there are other APIs they can access...

check on issue, we are talking about #1045

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

note: mobiel support

mobile

jeffH: this is about facets, you can have it on PC it is just a computer

gmandyam: i understand, but if app can't access a web authN API, then it is not relevant

christiaan: I thought it was and windows made api availabe

gmandyam: but if it is not a web authN api it is not applicable to the spec

tony: what is android doning?

christiaan: this is so high level. ...we do have to set up relationship but that is function of android not web authN
... this is documentation that android would supply

tony: same for windows. likely mozilla. close this because it is platform specific.

jeffH: even if we close it lets have link to it.

jc_jones: firefox is leveraging the platform

jeffH: linux will have to do it in some way.

tony: so this will get addressed in platforms, but we won't do this for Proposed Rec.

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

tony: on-going

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

tony: editorial

selfissue: is proposal to lowercase 'a'

tony: no, it is lowercase the 'N'
... we are back to #1051, also back to CTAP canonical CBOR coding

agl: I think this commenter just misunderstood.
... I think it is obvious what it means.
... I don't think this is a big problem

elundberg: and it will not change anything in Web AuthN

jeffh: correct

tony: we should close and say handle in the CTAP spec
... anyone against closing this one. and sending questions to CTAP

elundberg: I can do that

tony: takes us through open issues and tri-age issues. let's go back to #1050

https://github.com/w3c/webauthn/pull/1050

agL: we want to put this information into Chrome and want a rough sign-off from other browsers. If you disagree, lets get it out now.

gmandyam: wondering about privacy implications here. web authN can still work without knowing the transport hint.

agl: with chrome we are OK with disclosing this information

jc-Jones: I think this is going to be fine. I want to get another set of eyes on this from Tor community. They want to use Web AuthN

christiaan: we show the available transport and it is up to you to pick the one. in most cases, we can go right to correct set of transports for that user.
... nothing prohibits the RP from stripping out and not sending info dow.

donw

down

scribe: and we know it works without this. MSFT has implemented.
... I see some UX suffering. I want to get to point where we think in principle is OK

jc-jones: I think I can give thumbs up to principle.
... I just want to make sure in PR that we look at further edge cases.
... i can have the answer by Friday

Tony: Akshay will you look at this?
... did we lose him.

gmandyam: one more question
... is the browser giving up attestation to RP. If the attestation was never provided to RP, then I guess that would an indication that the RP will not get transports.

christiaan: I disagree
... the plan here is to revise what we did previsouly. say this is not a proper attestation.

gmandyam: I understand. But there are privacy questions.

agl: web authN has bunch of attestation and not all are X509-based.

john_bradley: transports are not in the attestation. they are part of attestation metadata, which is not for the faint of heart
... in favor of christiaan's argument it is possible individual transports can be turned off. could be security or privacy issues.

christiaan: I want browser guys to chime in. we thought long and hard. we want something the general public can use.
... even when surpressing attestation, we are still generating a new one and plumbing the transport piece through

john_bradley: that works for U2f, but not CTAP 2 (that was a statement, not a quesiton)

christiaan: I want to get closure on this issue. it is a major sticking point.

tony: who is not going to TPAC

agl: no

Rolf: I am not confirmed yet

tony: lot of things pegged for Level 2 with your (Rolf) name on them
... we want to get agreement on these things.

Rolf: meeting is Monday ( Oct. 22)

Christiaan: I will be there.

jfontana: yes, the 22nd

tony: anything to add to TPAC agenda. If so, push to list
... want to wrap everything by next week so we can submit on the 18th.
... we may have to punt on some issues to get there.
... hopefully more wrapped up next week and we can move to PR

adjorn.

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: weiler jcj_moz jfontana elundberg christiaan agl gmandyam John_Bradley Ketan jeffh nadalin
Found ScribeNick: jfontana
Inferring Scribes: jfontana

WARNING: No "Topic:" lines found.


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 05 Sep 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.)