Web Authentication Working Group Teleconference -- 22 Oct 2018

<weiler> Meeting: Web Authentication Working Group at TPAC 2018

<jeffh> scribe?

Web Payments meeting with Web Authn 9:15-10:30

Oct. 23

<weiler> 930-1015 tomorrow: joint mtg w/ WebAppSec

Also Web App Sec, 9:30-10:15 Oct. 23

<weiler> 915-1030 tomorrow: joint w/ Web Payments

<weiler> will sort out the conflict later

<jcj_moz> ((people introduce themselves)

Tony: Objectives and agenda
... goal is to look at what we want to do on Level 2
... we are in state of trying to wrap up Level 1
... success criteria for today. is to have plan going forward and which L2 items we will look at.

<jcj_moz> tony: main goal today is to look at level 2

Tony: and pick up any charter changes we may need.
... comments on agenda?

sweiler: join IRC and present + for everyone.

tony: any suggestion for agenda, objectives please voice them
... last meeting went through issue list for PR status
... i sent letter to FIDO Board to write letter on extension interop.
... the extension is we have extnsioins that are optional and non-normative. issue is implementations.
... we have an agreement that those that were interoped in FIDO we can use those if they are re-worked for the Web AuthN framework
... we have gone through them and map then to webauthn those from UAF and U2F from FIDO.
... and we make statements on interop
... there will also be a private letter listing the co. that have implemented these extensions.
... we have 9 extensions. 8 in UAF today, minus GEO-location
... the other 8 map to extensions that are already implemented in UAF
... the request was not a browser, it was for interop implementations. they have not been moved to web authn
... the logic of the extensions will remain, and it will be wrapped in inputs and outputs of Web Authn.
... that gets us to normative and options with the extensions.

jeffH: can we merge #1087

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

jeffH: RFCs are published, we just have to push merge
... it is a minor issue, but the repository is locked

jc_jones: Github is having a bad day.

jeffH: several PRs that do not have milestones, will they be labeled Level 2

rolf: so when technically possible we will merger #1087

tony: yes
... maybe github will add support for Web authn
... not promising anything.
... you will merge when Github is available.

jeffH: yes.

<wseltzer> W3C Workshop on Strong Authentication & Identity

tony: workshop coming up in Dec. in Redmond on strong auth and identity.
... call for papers has gone out for Dec. 10, 11 workshop
... trying to bring together blockchain, DID auth, and so we will look at this and see if makes sense as Web AuthN item.
... can we accomplish some of the same DIDs concepts into Web authn
... can this make life easier for all.
... look at what is common among blockchain, crypto algorithm, etc.
... Entitty Attestation Token work using CWT and COSE
... can take advantage of how keys are stored...
... take a look at the workshop announcement and see what questions you have.

<jeffh> who from sovern is in room>

<jeffh> ?

Ken Ebert from Sovereign

<jeffh> thx

<jcj_moz> s/Soverign/Sovrin/

Ken: there is not deep thought on hardware authentication

tony: I want to bring that into the discussion/

Dmitri: some DID people will come by this meeting for discussion. there is web authn demo with DID auth

<wseltzer> Workshop CFP

<jeffh> who speaking?

tony: Dec. meeting will be 60-70 people for meeting
... will look at papers that are submitted, and we will have time to discuss other concerns in the meeting

judy-zhu: how do you register

wseltzer: it will come with decisions on the papers that are accepted.

<wseltzer> workshop application

tony: anymore questions on the workshop
... Giri, can you do Entity Attestation Token now.

https://tools.ietf.org/html/draft-mandyam-eat-00

gmandyam: this is being considered in IETF
... meant to be data format

jc_jones: what about EAT is of interest to Web Authn

tony: we have many attestation formats in web authn
... maybe add this on level 2 and begin to collapse on various attestation. maybe acn reduce TPM attestations
... may fit into device recover work, say delegation.. will be some device recovery that will touch attestation

jc-jones: I see the intersection with CTAP, but don't see it with RPS

gmandyam: when we look at FIDO attestation. you have key store and safety net.

<jeffh> So what attestation format(s) does GOOG's Titan chip speak?

<jcj_moz> ack

<jcj_moz> q ack

<Zakim> jcj_moz, you wanted to is there something about EAT that is generally of interest to WebAuthn? Are we considering an extension to transmit an EAT from an authenticator up to the

jc_jones: my conern we have many attestations...

tony: this is option to reduce.

jc_jones: I don't think we are getting rid of some of this stuff, but I don't think we are getting rid of this, but getting something better.

jbradley: EAT could be another option of TPM

<jcj_moz> ... as much as I would love to not have so many attesttations

jbradley: we may have to add to some of these things in Level 2

tony: we are trying to see what we might do in Level 2, it's not that we are going to do this
... this is L2 perspective

sweiler: is there a working group for RAT?

gmandyam: no, no WG in IETF

sweiler: should we do this, lots of fingerprinting surface area here, that is scary

gmandyam: yes.
... I think privacy preservation is possible.

<weiler> weiler heard that as "yes, it is scary", not "yes, we should do it". :-)

rolf: what we have is a mess, it is a group of approaches.
... perhaps we can clean it up.

jbradley: having a format may let us look at other things like fingerprinting the devices.

<elundberg> rolf: better to standardise on one approach rather than have everyone make their own attestation format whenever they look into this space, which is currently happening

tony: the verifiable claims is mostly being used at ID, storng auth and strong ID need to have some linkage to form relationship
... we start to move into that realm here

jc_Jones: where is this discussed

tony: IETF
... if something happens at IETF in Bangkok then we will have to look at how we use this with Web auth.

<jeffh> wrt RATS at IETF-103 Bangkok: see "Remote Attestation Procedures (Approved for IETF 103)" here: https://trac.tools.ietf.org/bof/trac/#Security (scroll down to it)

tony: this will likely come up in EATs decision. some value here as a Level 2 option.

sweiler: do we do this instead of?

tony: some privacy aspects in attestation formats today, would like to do that with some attestation with privacy included by design
... getting at when EATs discussion happens at IETF, they will ask if we discussed here. We are not taking it on now, but we could look at it over there. Any objections here?

None heard.

break

<ericlaw> @jeffh: still chatting and waiting for folks to return from coffee

Return from break

Web Authn Recovery Extension

scribe: presented by Emil Lundberg

want to have one key that you use, one in "bank vault", lose main key, go to vault key

<Judy-Zhu> can we publish the slide in web?

3 actions state, generate, recover

<elundberg> https://docs.google.com/presentation/d/1gjrgrh0dURyxj4o-yfzrXt6f220XbUghjSo9vDb6O60/edit#slide=id.g1e605db387_0_9

<jeffh> 7?

Title is Ceremony Flow

<scribe> New slide: Recovery Extension

<jcj_moz> ack

<Zakim> jcj_moz, you wanted to ask whos doing the cryptanalysis

<wseltzer> http://crypto.stanford.edu/~dabo/

<Zakim> jeffh, you wanted to as which algorithm is used to create rB ?

<Rolf> near enough?

<wseltzer> Dirk's slides

<wseltzer> [slide: birth certificate, parentage "Security" and "Usability")

<wseltzer> ... with a seed from which keys are derived]

<wseltzer> weiler: two things that didn't get consensus, but were discussed:

<wseltzer> ... should user be notified of backup use

<wseltzer> ... delegation of permissions

tony: I am hearing there is interest in looking at account recovery for level 2
... next topic
... interest in DIDs. has ben workign on public key authn built into clients and browsers
... do we look at DIDs for L2, what do we do for decentralized identity

can someone from DIDs give an intro.

Manu volunteers to present

DID Auth can mean 8 different things, still working things out in group

some re-use web authn

Manu: worked with Adam Powers.
... we reused 90% of the work this group has done on this idea
... there are other ideas for DID auth

<wseltzer> DID Auth

Manu: there is not lot of interest in re-doing all this.
... a tension with privacy as opposed to authenticators.
... a doctor does not have privacy when he says this is my license.
... there is a range of privacy. where you are on the spectrum people make different choices.
... it is a big community. It re-uses some Web authn, but in other areas it does not use web authn

tony: one thing this group can bring to table is notion of authenticator. with blockchain it is hard to tell where the key came from.
... lot of work here has gone into hardware, like with attestation, so yo can tell what is going on with key
... we can reuse these tokens, and the tech is built into platforms, the transports; think all this will matter to blockchain group
... and CTP will go to some standards body soon

manu: there is deep interest in doing that.
... there is some option to have full anonymity, but in these cases, I don't think we would re-invent FIDO, web authn
... I hope that sounds that we want to re-use the work that has been done here.
... do people believe that? Or do you see something that that is not the case

tony: wondering if blockchain use case work into the next level of web authn work
... do we want to take this one. what happens in workshop in Dec. , can we get participation from blockchain community. what can we do together

jbradley: one thing that would help is algorithm support.
... right now we have algorithm agility ...is there something we can get consensus around?
... there are other things. specing out extensions, signing?
... there are incremental things we can make progress as we find out what DID can bring

tony: can you store DIDs in authenticators, do we play a role in storing these documents on my authenticator so we are not storing things on the cloud

dimitri: for Level2 discussion. would it make sense to tak on some of the more public use cases, like restrict pair wise to RP for public identifiers.

tony: we will talk about origin. maybe we use policy, we will discuss

jbradley: whether authenticator or client can relax policy, can we have that?
... we need to make sure we don't open up MiMA

Manu: specific limitations we ran into. in credential handler...we run it in iFrame... current interfaces are not useful.
... we have demo, if there was safe way to enable that to work, we could do a bunch of experiments.

jbradley: Web payments have the same issues, key is doing it so we don't shoot ourselves in the foot

Nathan: curves......???

manu: one thing is to adopt COSE style structures.

Nathan: we have to store lot of things in wallets and chains, we share thoughts on how to do that efficiently

tony: EAT token
... lot of attestation out there today that do not preserve privacy. We are looking how to build that into attestation

<Rolf> Curves: there was desire to add Edwards and secp k2 curve

manu: that is stuff that can be re-used. some of verifiable claims use cases are very broad.

jbradley: consumers, it's hard to explain differences between identifiers, so we opted for most privacy preserving. when you don't user ed becomes very important
... web authn always has the property of doing the most privacy preserving things

rolf: we still allow RP to open up things, it might be OK to publish to use it in more larger aspects

manu: this is concern and requires more discussion.
... my hope is we can have this discussion
... that consumers are safe.

tony: I am hearing, this is something that we have support for looking at these issues as far as DID auth is concerned.
... how to we utalize web authn today and the authenticator. we already have them

manu: yes.

tony: not hearing any objection on looking at this for Level 2. We might have to look at the charter. Maybe it fits under the charter today

wseltzer: we will be looking at the charter in light of the discussion we are having and see what we want to include.

tony: makes sense to do the work here, we have the expertise.
... the other thing is to get support from DIDs to join the working group when we get there.

<wseltzer> Current charter

tony: OK. anymore discussion on DIDs, blockchaing.

manu: Wednesday there will be a breakout on a DID proposal

<wseltzer> Wednesday breakout proposals

Editorial Issues for PR

tony: look at #1096, #1097 #1098

<wseltzer> https://github.com/w3c/webauthn/issues/1098

Hober: editorial concerns to be worked out.

<wseltzer> https://github.com/w3c/webauthn/issues/1097

<Rolf> any issues marking section 13 explicitly as non-normative?

<wseltzer> specifically, re the FIDO reference3

<wseltzer> [[Proposed change:

<wseltzer> Strike:

<wseltzer> "Also, the [FIDOAuthnrSecReqs] document suite defines authenticator security characteristics which are overall applicable for WebAuthn authenticators."

<wseltzer> ... and replace with:

<wseltzer> "Also the [FIDOAuthnrSecReqs] document suite provides useful information about authenticator security characteristics."]]

<wseltzer> https://github.com/w3c/webauthn/issues/1096

<wseltzer> jeffh: ok [re 1097]

<wseltzer> [[1096: The paragraph beginning "Broadly, compliant authenticators" is unclear. It should be reworded to state that implementation is possible in software executing on (a) a general purpose computing device, (b) an on-device Trusted Platform Module (TPM) or a Secure Element (SE), or (c) off-device. ]]

<wseltzer> nadalin: does that resolve your issues?

<wseltzer> hober: I think so, and will make sure Brent reviews the PRs

<wseltzer> [break for lunch, resume at 2pm local]

<weiler> [one hour and 21 minutes from now]

<elundberg> local is UTC+02:00

<mmayslich> Webex: https://www.w3.org/2016/01/webauth-password.html

<weiler> kim: new features in chrome 70: touch ID on OSX, new UI, and @@

<weiler> ... android is just U2F

Google demo

Chrome 70 Web Authn demo

<weiler> right now, on chrome, when browser data is cleared, fingerprint auth link is lost.

Authenticator Selection enhancements https://github.com/w3c/webauthn/issues/441

<elundberg> gmandyam: authnr selection is useful for biometric applications: set bounds on FAR etc

<elundberg> cbraand: we don't want to make it easy to cherry-pick specific authenticators

<elundberg> cbraand: we would prefer to not expose an API that invites ecosystem fragmentation

<elundberg> ...we know that RPs do shoot themselves in the foot

<elundberg> rolf: what about adding generic criteria on execution environment

<elundberg> ...would solve PSD2

<elundberg> cbraand: we're looking at that

<elundberg> ...if we are generating keys on android we guarantee to use the keystore

<elundberg> ...which on android is hardware backed

<elundberg> ...on other platforms maybe something like that makes sense

<elundberg> ...I'm not sure about doing this in an up front way

<elundberg> gmandyam: this is required for financial applications in china

<elundberg> cbraand: you can still do that with attestation

<elundberg> gmandyam: yes, but it would be useful if the RP could signal requirements to the client beforehand

<elundberg> cbraand: what's the alternative/fallback

<elundberg> jbradley: there may be differing expectations

<elundberg> ...current impl on android (maybe future) will have one keystore

<elundberg> ...other people from other protocols may expect different keystores etc

<elundberg> ...current UAF you may have different authnrs with different security reqs

<elundberg> ...on android there's only one

<elundberg> ...so selecting between one and one isn't useful

<elundberg> ...that might not be the case on other platforms

<elundberg> cbraand: if we do this right there will be something on the platform that'll suffice for 99% of cases

<elundberg> gmandyam: we ship 3 biometrics today

<elundberg> ...all have different qualities

<elundberg> nadalin: microsoft has three put forward for certification

<elundberg> ...every windows branded laptop will have all 3 of those authnrs

<elundberg> cbraand: as an RP how iwll I choose

<elundberg> nadalin: it's the user's choice

<elundberg> ...they have different security/usability characteristics

<elundberg> cbraand: so you want the user to pick

<elundberg> ...so then there shouldn't be selection criteria for the RP

<elundberg> ...as an RP should I treat these differenty?

<elundberg> nadalin: they're three different authnrs we've registered metadata for

<elundberg> cbraand: on android if you register a key with fingerprint, you can later log in with screenlock or whatever

<elundberg> ...that won't work if they're separate authnrs

<elundberg> ...is the idea that RPs should tell users what to do, or let user pick

<elundberg> ...in consumer space I don't think user will know

<elundberg> nadalin: windows hello may guide them well enough

<elundberg> cbraand: we're very afraid of making this more confusing than it already is

<elundberg> nadalin: I think we have use cases for both enterpirse and consumer

<elundberg> ...we have the use case of RP choosing

<elundberg> ...and of user selecting

<elundberg> ...but there has to be more than one authnr

<elundberg> ...I think cbraand said they support only one platform authnr

<elundberg> jbradley: yes, so that may not give RP any advantage on that platform

<elundberg> ...may be useful on other platforms

<elundberg> cbraand: we argue against that use case

<elundberg> rolf: how would enterprises do that selection?

<elundberg> cbraand: through extensions

<elundberg> ...which Chrome probably won't implement for now

<elundberg> ...we want to see benefits before doing that

<elundberg> rolf: let's stick with what we have for now

<elundberg> ...do we close #441?

<elundberg> gmandyam: I think not

<elundberg> nadalin: I think not

<elundberg> cbraand: I'm okay with not closing

Silent Authenticators https://github.com/w3c/webauthn/issues/199

tony: jeffH opened this
... it was paypal issue
... rolf may be better to talk about this, about how they are deployed.

rolf: there are authenticators for this, but we did allow some authenticators through the backdoor.
... they are there in the platform.

jbradley: isn't this a CTAP issue
... thought we were trying to get rid of this, adding would be interesting twist

rolf: do not want to get things in through the back door. we have to think about the privacy implication

jbradley: is there really..we don't have silent in web authn, closest is NFC tap (more a gesture)
... web authen does not have silent. we can talk about credentials and credential IDs, that is separate discussion

cbrand: spec says you can't do this

rolf: this is normative spec, at this point it cannot be silent, a normative change could make it work

cbrand: I see where it can make sense.

jbradley: we said that's a bad idea because it creates a super browser cookie

rolf: what we have is at the other end of spectrum, need user interaction every time.
... but what about time window fro not have to do authentication

tony: any blockchain requirements where this is an issue

gmandyam: web authen comes in if it is a web of things product.

Nathan: in blockchain we talk about a proof request ...I don't know if there is one good answer. I need more time to find how web authn is composing this answer

rolf: no immediate action on this

tony: still need to consider for L2, and for blockchain.

nathan: when you broaden past just authentication it gets really messy

hbradley: and raw CTAP may not be avail on all platforms all the time.
... right now those APIs are out of scope for us.

tony: any more on silent authenticatiors
... leave it open at Level 2. need some input from blockchain folks.
... next topic Biometric Accuracy https://github.com/w3c/webauthn/issues/445

gmandyam: there is this in form of extension, rather have it as part of API structure.
... but not at that point yet.

Dimitri: what would be the use case for this
... as app dev when do you specify the threshold

gmandyam: there are some parameters that make sense. some of this is onvenience, wich is not for high value transactions.
... we think facial recognition that would be suitable for financial transactions.

rolf: the RP makes that decision.

cbrand: it can come from the metadata

gmandyam: I think the RP would do this if this is not here. RP reads metadata and decide on authenticator or go back to user and ask for something else

cbrand: there are some enterprise examples of this.
... do we need all these additional controls.

gmandyam: this was create before I created the extension.

cbrand: this is OK for extension, but not for main spec

rolf: for me another aspect. side effect of diff biometrics, have to make sure it is the same person behind it. Friendly fraud.

cbrand: friendly fraud is the last concern.
... extension sure, not sure it should be in main spec

gmandyam: fido is only going to test to certain bounds, and those fall way short of what financial guys need

tony: some would like this just as extension.

gmansyam: I would say no consensus to move from extension to core.

UAF Signature Formats https://github.com/w3c/webauthn/issues/465

rolf: to make UAF signature format legal to use. the server can handle.

tony: does that cover signature

rolf: in this case yes.
... lets talk signature format, we are not talking attestation anymore. now want to connect to mobile devices. CTAP is already in the spec, but what the browsser sees is a UAF assertion
... how can you make sure this different UAF assertion would be passed through to the browser.

gmandyam: why would you pass this through

rolf: it would pass like anything , it is just the payload.

tony: if we can get this worked out here, it might help with the blockchain folks later.

rolf: what are the things we need to put as notes in the spec. pass these things through and all this would work

jc_jones: this only supports direct authentication?

rolf: one use case the authenticator is already registered, so attestation is done. so now the user just wants to authenticate

tony: we are only answering for signature]

rolf: maybe crate two issues. accept nominated sig assertions, and then one for other cases, say a blockchain case.

gmandyam: so we would only be interested in accessing the already created registrations.

rolf: if you could use what is there, that would be great benefit.

gmandyam: title of issue is fine. the content may not be accurate.

rofl: so I jst re-title it. it is snot specific to UAF. Will be other use cases.

rolf: use case is browser would pass thorugh UAF signature assertion\

cbrand: I think this is academic at this point, not sure we will use it.

gmandyam: i think you are saying you put something it that speaks CTAP outgoing

rolf: there could be implementation that requires no work

tony: maybe just pass it through now, maybe no work
... think we should at least take care of issue with 96% of authenticator

Attestations (Safetynet) https://github.com/w3c/webauthn/pull/1010 https://github.com/w3c/webauthn/issues/968

gmandyam: the demo shown by Google, two diff. attestation formats on android today. I think they are for two different things.
... you have safetynet - think Google is evolving , so that is what this proposal was about , not to say either or, but to allow for integrity check for key store attestation
... that is what we defined. this PR does not remove safetynet. but ai want to bewtter fit safetynet into attesation
... feedback I got was not negative, but thought was this could not be done in neaer term.

cbrand. in general move to place where on every get you can get info. about the platform

cbrand: I saw this at black hat , continuous attestation from microsoft

<jeffh> I'm going to be busy here for an hour.....

Feature Policy https://github.com/w3c/webauthn/issues/911

Tony: looking at top level domain policy

jc_jones: i think this is the expected way to go about this
... we need a heading that says feature policy is Webauthn, and both algorithms needs to call feature policy instead of just aborting if feaute policy does not hold
... spec is fine.
... do we make it normative and mandatory for Webauthn

cbrand: think we should make this mandatory

tony: we would be in favor of this, we have not implemented yet
... it's a when

cbrand: this allows an iframe to exercise the credential for different origins and domains.

tony: not hearing any objections to looking at this for Level 2

Synchronizing Platform Authenticators https://github.com/w3c/webauthn/issues/969

tony: Google are you in favor of doing this.

rolf: I want to understand what this means
... I think this is about sync the private keys.
... but I have been told differently

cbrand: I think this is almost orthogonal. but I think it has to do with private keys
... signal is RP says I log in on mobile banking web site. RP says this is OK and later syncing. the RP would make that decision

rolf: FIDO has said that the private key would never leave the authenticator.
... we take it to some cloud key storage and they move it to this device.
... there might be authenticators out there that do this backup.
... they might limit this to keys that are not FIDO certified .

cbrand: the reality of a world without passwords. right now we only use password once. to eliminate that we have to do some sort of federation.
... for some RPs that would be fine.

rolf: the challenge is that impact is big.
... it will have unintended consequences
... if you give the option, people might implement.
... it is fine line we have to walk to be transparent to RP what they get and don't get.

cbrand: this is more about transparency. RP can turn around and move the private key.
... we have to let them know.

rolf: at least make sure the honest authenticator venodrs that this key will do backup or I don't want to do this.

elundberg: does this solve problem we can't sovle with attestation.

cbrand: maybe there is a point where private keys are backuped up in the cloud - and for 99% of users that is acceptable.

jbradley: one obvious issue, if you only backup to one devices that is useless.

rolf: I think some vendors will just do it. How do we stop them.

gmandyam: I don't know if you can get so expressive in the API to do this.

elundberg: do we have a use case for this.

cbrand: say Google and Apple want to do it tomorrow
... maybe RPs have regulatory reasons not to backup key.

rolf: you could have controls so you could only backup to a certain state.
... some regulatory environments might be able to handle that .

cbrand: I don't think this is immediate in any way, but we need to be prepared.

rolf: this is just an issue.

tony: what I am hearing there are some use cases that this is useful for, and some potential danger for allowing this to happen.
... danger is thinking that this can be implemented. I think there is some consensus to look a this for level 2 but in a narrow, scoped way.

rolf: ..and what does this mean if they hit the market.

Same-origin revision https://github.com/w3c/webauthn/issues/1001

tony: we talked about this.
... my understanding if cred man we would have some changes, but credman would have to pick this up.

jc_jones: I don't think so. credman just gives us a switch and we deal with how to handle the swith

tony: so you think this will not require any additonal credman support?

jc_jones: I don't think it does.

tony: (mike west enters room) do we have issues with credman

jc_Jones: it looks like basically it is delgate dot web authN

mikeest: you have to be same origin as all ancestor or we reject, now. now we send a boolean along with request and the specific credential type can determine behavior, either true or false. so it is this groups decision
... it seems reasonable for you to do work too checking against relevant feature policy and to accept or reject.

jc_jones: I don't think there isn't anything left with this issue.

correction jc_jones: I don't think there is anything left with this issue.

<jeffh> issue #1001?

tony: close this one and refer to the feature policy

Feature policy, JeffH.

<jeffh> see https://github.com/w3c/webauthn/issues/911#issuecomment-407582250

this one is #1001, yes.

Trust anchors https://github.com/w3c/webauthn/issues/1063

<jeffh> for #1001 see https://github.com/w3c/webauthn/issues/1001#issuecomment-406062643

gmandyam: i was assigned this.
... in L1 we said this would not be part of API service, so I tried to define as extension.

tony: Google is this something you are after for trust anchors for U2F

this is for root trust for attestation

cbrand: we were not pushing this.

jbradley: were discussion that chrome only passing attestations that they could look up in metadata service.

cbrand: yes.
... is this related to this

jbradley: no, i just made that up, but it seems likely.

cbrand: i think this is fine the way it is.

tony: christiaan you want to close this one.

cbrand: yes.

Provide Transport information during registration https://github.com/w3c/webauthn/pull/1050

jc_jones: I have problems with this. Looks like my change was taken care of by Adam.
... I want to go back and make sure.

tony: you will let us know

jc_jones: yes.

tony: any other particular issues. Christiaan, i believe you had one. you wanted feedback on the the issue. Maybe it is there.
... we have an end date of Sept. 15 2019
... with this work we will likely run over that date.

sweiler: as long as you have stuff going on, you can get a re-charter. I don't think it is an issue.

tony: so that puts us out 1 year. 2?
... this was the last thing I had , to extend the charter.

- DRAFT -

Web Authentication Working Group Teleconference

22 Oct 2018

Attendees

Contents

Editorial Issues for PR

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output