James: Network based transport via https for Web authn
... user don't want to think about authenticators

as adoption increases, what will authenticators look like? what we have now may still be popular

scribe: we want to enable workflows,
... how many poeple here familiar with caBLE?

lots of hands up

James: it is for mobile roaming use case

eliminates a Blue tooth pairing case

bluetooth is not always avaialble and it would be nice to have network based transport,

Ctypton, has anyheard of it. mobile based authenticator

Crypton

they are doing this in the wild they are over ridign the navigator credential object.

Nick: they see mobile doable with an extension
... but they can read every page you go to.

second issues with this. the

scribe: it can be an usafe solution. they are implementing their own thing
... we see it degrading security.

James: we have talked about it on some web authn calls.
... now is time to ponder on this problem before the ecosystem is degrading any further
... not picking on Crypton.
... we have built a pro-type

Gerhard: when U2f first came out we had to work to make it work, we wanted to do it from the browser
... we built a chrome plug in , and went to bank servers, it was lots of effot
... we want this type of approach, but do not want to break stuff.

james: next point. we think cable and https can work together
... we are interested in preserving properties, like anti-phishig. we think we can keep that.
... we think cable can be phished.

JeffH: the term is phishing resistance.

Google disagrees with DUO

nick: phishing resistance is provide mostly by origin scoping to enforce,
... want to continue this.
... we thik we can maintain properties

jbradley: part of issues may be idfferenct definition of phishing resistance.
... attacks are different, don
... don't know if they are completely resistance, need to anlyze other parts.

jeffH: we disagree

nick: couple parts of hhttps transport may include serialization.

send web authn structures up to server for checking other operations.

james;;; lookding at based 64 and...

scribe: configuration is key
... need pairing. for phishing resistance

having a crypto channel btween chanel biding and authenticator is must

scribe: Proopsal. webauthn JSON vai HHTP
... should it CTA

ctap

scribe: proposal cBOR via CTAOP or HTTP

CTAP

scribe: not big on this idea.

nick: one other idea. if https too presecriptive.
... we think browser can reflect trasport in a more generic eay.

way

we would aloow APIs that extesions could register with.

scribe: this idea is not fully fleshed out.

James showing demo.

scribe: demo over

jeffH: are you goiong to make your write up public

nick: yes.

james: reason we decided to keep this session is to get feedback
... we know there are issues with network gtuff

jeffH: phishing resisteance of web authn, it is not just origin scoping. it is more with a cryptographic protocol.
... nothing you can do to get someting to replay and act as user.
... you can man in the middle this pariing.

JeffH on white board

jeffH: from our presepeictive this is a non-starter, it is phishable.
... origin stuff - scoping and proximity, are requried together for registration. otherwise, you get in a phishable situation

nick: the architecture is not allowing a web site to talk to your mobile device.
... we think we address your concern
... in a normal case, users have authenticator and mobile device.
... our proposal. we allows users to pass a message
... the service on the netowrk, is some separate site that passes message between browser and mobile authenticator

jeffH: why?
... I could create a message passer

nick: we are using a QR code to establish a channel to message passer
... the passer can deny, but can't inspect content

jbradley: biggest issue with QR code - it is uni directional . so no bi-directional
... begtween user agaent and third party is addressed by protocols
... this is about using CTAP

jeffH: we havethinking on this.
... we think we can use cable to help establish the binding. then you can use standard transport for DUO proposed transport

nick: we agree

jeffH: key thinkg here; server and the laptop and the phone. security is here.
... don't hav eto do over bluetooth. can go over usb
... but phone and laptop need to talk to each other.
... we have boiled caBle to phne and laptop pairing.
... don't do the round trip
... the connection is bi-directional and encrypted.

jbradley: figuring this out, the https then may be of equivalent secruity.

jeffH: we are looking at caBLE in this context.

jbradley: need to include CTAP in this. you want to take advantage of web authn to the platform and allow CTAP to talk over transport.
... messing with this is more trouble that it is worth.
... there are a bunch of things going on here.

nick: we can't rely on a platform. we run on the web.

jeffH: tis distinction is nailed down in the spec. it is called client platform.
... our beef is making sure the binding is secure.

james: we want to increase adoption.
... we want to support as many use cases as possible

jeffH: we like that idea

nick: want to show there are some things broken and we can fix them.

Gerhard: our ideal scenario is you can take a fido token and use it anywhre.

jeffH: I want to use the term binding, not pairing.

gerhard: I just want to say, once I pair and have a session, I want to reach out to a phone in a trusted way.
... it is not always user initiated. but once I have consent, I want to reach out for a new cryptogram

jbradley: this is not really what this is for.
... you are talking binding of platform authenticator...

nick: yor use case scenario is not enabled by this

benjamin: looking at fido for web payments and the adoption is not here. this looks interesting.

jbradley: but this is designed to not have a plug-in.
... deal with this as a transport and let the platform negotiate for the transport.
... i would lean toward defining it in the spec, and let the client platform do its end of it.

jeffH: we want this to just work

james: that is what we want also.

rssagent, draft minutes

rssagent, make logs public