As per comment#0 this seems to be security key related, hence forwarding it to Inhouse. Could someone from Inhouse please help in triaging this issue.

Thanks!

We have no 

To finish my incomplete sentence from comment #2.

This seems like a policy request which we generally do not do but over to the WebAuth team since it is in their domain. I believe the correct avenue is for the customer to escalate this with Vanguard.

Mike, do you know if they are actually blocking registration of security key models outside of that list?

They do block. Turns out they do accept the new FIDO2 blue security key from Yubico (thus I retract "and not even the four most recent that company produces!" although it's possible that Yubico is using the same attestation cert as the v1 of the blue SK), but it absolutely does reject the inexpensive Feitian U2F device. See attached screenshot.

Vanguard is the only firm I've encountered that actually makes you agree to a specific U2F ToS when you set it up: https://personal.vanguard.com/us/U2FKeyEnrollment#/consent. This is not relevant to the bug report.

Deleted: vanguard-feitian.png 19.5 KB

	vanguard-feitian.png 19.5 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

+agl@, who might have opinions.

mike@ Could you please help us with sample credentials or html page to triage this issue from TE end

Thank You...

Neither of those requests is reasonable. I'm not going to give you my Vanguard account password, and I'm surprised you're even asking for them. The screenshots I've already provided are enough to see the issue. HTML would provide no more information whether Vanguard has a policy of rejecting specific brands/models of U2F keys.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Mike, apologies for the miscommunication on our side, I forgot to remove the NeedsTriage label, which confused the TE folks. We don't need more data at this point, and certainly not your Vanguard account password.

As a next step, I would like to hear what other people who are CC'ed think, although today is Memorial Day in the US so I suppose most folks are out. I'll assign this to myself for now.

We have been in contact with Vanguard about this a couple of times and we agree that this is not the way that we want to see sites supporting security keys. We are choosing to continue working with them rather than taking more active measures at this time:

1) Vanguard are an early adopter of security keys and we want to encourage this in general. 

2) The FIDO metadata service (which, if you want some form of attestation checking, is supposed to be the source of truth) is still incomplete and the ecosystem around it isn't yet developed.

3) FIDO were, last I heard, revamping their defined security levels and I don't know if that process has completed yet.

So, as unfortunate as this vendor lock-in is, Vanguard would have a fair argument that the "right thing" is not yet ready and thus this stop-gap is more reasonable in that light.

We continue to watch developments in this space and hopefully the MDS will mature to the point where it's the obvious and easy answer. We're very interested in hearing about any other sites that may employ a similar attestation policy and, as you've probably noticed, we introduced a permissions prompt for sites wishing to obtain attestation information in Chrome 66.

Thanks for the overview, Adam. I see the need to be more lenient while community building. At the same time, I worry that this behavior from a name brand like Vanguard will become a U2F best practice.