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