Hadley: I would like to have a proper look at it.

Dan: I suggest we look at it right now

Dan: In the security & privacy responses they've said there us no special behavior in incognito modes... Should there be? If the user is using an Apple Attestation it will leak that they have an Apple device. Other than that the responses to the privacy & security self check look good - however I'm unfomfortable with the apple-specific fingerprinting issue.

Hadley: looking at the explainer - talking about features that are changing but doesn't talk about use cases and user needs... The desfription of attestation doesn't say "why"...

Dan: written from a perspective of people who understand the space of authentication.

Hadley: webauth level 2 - adds discoverability of credentials for the relying party web site to examine - and I'm struggling to understand why that's a good thing. When the user wouldn't want them to be discoverable... They haven't explained what they're setting out to accomplish. Looking for use cases... large blob is for ssh authentication.. credblob is for non-web context.. what's in mind for that?

Dan: in level 1 there are use cases. None in the explainer for level 2? It talks about machine auth in a non-web context..

Hadley: Right, what does that mean? There are use cases in the spec.

Dan: same use cases as in level 1. A question about what additional use cases are being enabled if thare are no new ones in the spec and none in the explainer.

Hadley: Mike also asked for use cases

Dan: we can ping Adam and say we agree use cases are lacking and link to that comment

from blink thread

The situation is that a credential is getting created on a security key via the web, but it'll later be used in a non-web context. In Microsoft's case the credBlob value will be the SHA-256 hash of some Active Directory stuff. When the user is signing into a new laptop then this that serves to convince the new laptop that the information that it's getting over the network isn't lies. It trusts that the legitimate owner inserted their security key, but it doesn't know that the network is friendly.

That is not a precise description, and I might have misunderstood some details! The reason that I think the details are unimportant is that there's already a binary blob that a website sets on a new credential and which is returned when the credential is used: the user handle. So this information could be hacked in there, but Microsoft are doing it more cleanly. The only reason that this involves an IDL change at all is because of the way that authenticator extensions happened to be implemented in Blink.

Peter: that is specific to the credblob

Rossen: this is an important use case

Hadley: the next question is Yoav saying who wants to ship this, the answer is Microsoft at the moment. The rest is addressing edge cases needs. If this is to do with desktop auth why does it need to go through the web?

Peter: the enrolment happens on the web. They're wanting to reuse webauthn for other purposes. Log into your corporate laptop with the same thing as you log into corporate websites. There are other use cases like sharing SSH keys, probably part of the original intent. I'm concerned about the Apple extension being a vendor specific.. assigned to a generic web platform API seems odd to me.

Hadley: not normally how we do things. Also one for Android. There's a design principle about not doing things specific to one vendor. There's an ethical web principle about multi device

Peter: we have a principle about native apis not translating well to the web

Dan: [noodling on some comment text]

`Hi @mikewest @agl. Sorry this dropped off of our radar. We are spending some time looking at it today. We're noting a lack of use cases. It looks to me like the use cases in the level 2 spec are the same ones as in the level 1 spec - so this raises the question: what additional use cases (user needs) are being solved with level 2? Our take on explainers is that they should generally start with the user needs. I have no doubt that there are important new user needs that y'all are trying to solve with level 2- but it's not clear from the explainer what those are. Even if the answer is : "this spec adds some commonly used authentication mechanisms to webauth."

Regarding the security & privacy self-check, the responses look good. I'm concerned about the fingerprinting implications of the apple-specific attestation format. There doesn't seem to be any discussion on mitigation against that. Also, there are no plans to have different behaviour in incognito mode. Is that a good thing, especially considering the additional fingerprinting surface area? Do you have additonal information about why device-vendor-specific mechanisms are required? It's unusual for device vendor specific technologies in the web platform - see Web Platform Design Principles and Ethical Web Principles.

One side note: the explainer and response to the security & privacy questionnaire are both in google doc format and we'd really like to encourage these to be in markdown along side of the spec itself...

We're aware we took too long on this review and we're not seeking to block anything, however the we think the quality of the explainer and spec will be greatly improved by addressing the above issues.`

Dan: posted. See if we get responses by wednesday?

Dan: we left some feedback, we got a reply.

Hadley: seems like compensation for the fact there isn't standardisation somewhere else - need to support different vendor attestation formats - coping with all that complexity rather than having a format for it. Sounds out of scope ofr this group, but it's a shame.

Dan: considering the cross browser support I don't know how useful.. where to put our energy? Push on that issue, or leave it as a closing comment?

Hadley: the concern is that in our original feedback in March we asked for information about device vendor specific mechanisms being required. They said because the world is complex and that's what we've got to deal with

Tess: true

Hadley: looks unfortunate to be baking that into the web when it goes against our design and ethical web principles. But I don't know what they can do differently.

Tess: don't think it's as concerning as that. The website is in the middle. One side you've got authenticators from different vendors that have different security properties. On the other hand, backend services that the website has to deal with that migiht have their own reqs about what kindof security is good enough. Putting aside the vendor specific question, we were always going to end up at a place where there needs to be some kind of negotiation between the client with an authenticator and mediated by the website and the people behind that who have requirements. I think they were always going to end up with a technical solution with this level of complexity. That had multiple attestation formats, different authenticators with different characteristics. Unsurprising market reality that some of those distinctions have fallen on vendor lines as opposed to other lines. Don't disagree, but would be surprised if in a world where we didn't have this on vendor lines it would be other lines.. and the architecture would be the same or more or less the same. Architecturally I don't know if they're doing anything wrong. Reflecting reality of different platform authenticators and people like banks and govt agencies have different requirements. Probably okay. But we don't have to be happy about it. This is much better than EME, which has complete black boxes. In this case the different attestation formats are formats you can inspect and see what they say and verify cryptographically that the person you think said them said them.

Hadley: agree.

Dan: close with recommendation that we think this is problematic and we understand the compelxity and constraints but we wonder if there couldn't be a better..

Hadley: I'd like us to do that, in the future we'll want to know what we were thinking when this came up, be nice to have those comments in one place

Dan: I'd like to push on the incognito thing as well. The response to my question is reasonable.. it's gated behind a permission.. might want to consider it being done differently in incog

Hadley: response.. I'm not sure how it answers question. User is opting into fingerprinting?

Dan: yep

Hadley: okay? not sure user is going to get that

Tess: imagining the case... comes up because i have a keyfob authenticator thingy and I'm using someone else's computer to log into my bank, so I start private browsing, go to bank site, log in with 2fa, browser asks for permission, I say yes, do the hardware dance, now what has the site learned about me that it didn't already know?

Dan: learned the type of computer you're on

Tess: which in this scenario is someone else's. Interesting because it adds to the overall sense of where I spend my time and who with, but they only have general device fingerprint, but also IP address

Dan: already know what kind of computer you have because of the UA string.. if you were using private browsing you could be obfuscating that

Tess: they have a better idea of the computer you're on than before. If it's incog on your own device and you're using a platform authenticator they might learn a lot mor eabout the device you're on because only certain devices are capable of doing that. Myabe part of why this is hard is you use webauthn on banking sites.. places where they already know a lot about you. So people say of course they're going to learn about you. We have these very silo'd part of our lives. My bank knows all about my finances but not my sexual preferences... probably figured out from credit card history.. but a lot of things your bank doesn't know because you try to silo them into financial stuff. If theyr'e able to learn enough about your device in incognito mode because you used webauthn where they didn't have enough to go on before, if that was th edelta they ndeeded fingerprinting wise...

Dan: mistake to make the assumption tihs is only going to be used for banking or financial services

Tess: agree, not assuming that. Even if you restrict the analysis to the case where it's highly sensitive, it's usually a case where they might kno sensitive info but it's siloed. They could learn a hell of a lot more by fingerprinting, especially if they work with a third party identity broker they can cross link and learn other things that are none of their business. That said, it's probably the case that it's easy to fingerprint users in incog mode already. Not any worse than status quo - crappy argument, status quo is unacceptable

Rossen: bad argument

Hadley: agree. User giving permission is also bad. "access to learn about your keyfob and also match it with high accuracy a bunch of other information?" wouldn't be in the permission

Tess: permission is targeted - just want auth - not give the keys to the theoretical mansion

Rossen: META: do we need a "Resolved : OK with concerns"

Tess: if we're going to close it in that state we should make sure the steps to remove that concern are clear. Disable the feature incog mode? Conflicts with principle about undetectability of incog

Dan: making it more clear to users that information is being shared with a third party that could allow them to be tracked?

Tess: yeah. probably the case that they can't prescribe ui stuff, but can add a note to the spec saying when you ask for permission here make it clear that there's more to it than just doing the authentication. UA probably won't follow that adviec because number of words in a prompt is small

Rossen: even those who do it, users are not necessarily going to... even if they read it.. not going to understand the implications

Dan: when it has to do with tracking, just read only 5% of people are turning on tracking. People are not just tapping that away.

Tess: would you be satisfied with them adding a non normative note to the spec?

Dan: would be fine. They should add something in the considerations section?

`Having said that, we understand the constraints you're under regarding the attestation formats. For our own notes, we'd like to say that it isn't ideal to bake vendor-specific attributes into the web platform and that it would be ideal if they all converged on a standard. But we recognise that is out of the remit of this work.

We remain concerned about fingerprinting. The argument that users give permission feels weak to us because they are not explicitly giving permission for access to information which could be used for fingerpinting (and down-stream tracking). Could a note be added to the spec (eg. where the feature is described as well as highlighted in the privacy considerations section) that could guide implementers that when users accept the prompt they may be sharing information that could allow them to be tracked?

Other than that we are fine with this work. Thanks for bearing with us regarding the long delay in getting you feedback.`