Drop SiteBoundCredential in favor of CredentialUserData

third_party/WebKit/Source/modules/credentialmanager/CredentialUserData.idl

 // Copyright 2016 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
-// https://w3c.github.io/webappsec-credential-management/#siteboundcredential
+// https://w3c.github.io/webappsec-credential-management/#credentialuserdata
 
 [
-    RuntimeEnabled=CredentialManager,
-    Exposed=Window
-] interface SiteBoundCredential : Credential {
+    NoInterfaceObject,
+    SecureContext,

[jdoerrie, 2017/04/20 12:58:02]

I'm unsure about this, I basically just copied it from the spec:
https://w3c.github.io/webappsec-credential-management/#credentialuserdata

Given that |RuntimeEnabled=CredentialManager| is present in the other IDLs, this
should probably be kept, no?

[vasilii, 2017/04/20 14:21:31]

For now yes. But I think we can drop |RuntimeEnabled=CredentialManager|
everywhere and in RuntimeEnabledFeatures.json5 too

[jdoerrie, 2017/04/21 08:14:57]

Alright. Does |RuntimeEnabled=CredentialManager| actually imply |SecureContext|,
and if yes, should I drop |SecureContext|? According to the spec |SecureContext|
should be present on FederatedCredential and PasswordCredential as well, but
there I also only see |RuntimeEnabled=CredentialManager|.

[vasilii, 2017/04/21 08:42:59]

RuntimeEnabled=CredentialManager is just a name of the feature which can be on
or off. It doesn't imply anything.
SecureContext should appear on the interfaces. Currently I can create a
PasswordCredential on a HTTP page. I think it was added to the spec recently.

[Mike West, 2017/04/24 07:34:08]

I agree. If y'all would like to remove that in a subsequent patch, I'm happy to
stamp it. :)

+] interface CredentialUserData {
     readonly attribute USVString name;
     readonly attribute USVString iconURL;
 };