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.)[End of scribe.perl diagnostic output]