2018-04-19 12:06 AEST by Arthur Barrett - The SSPI protocol/authentication plugin currently supports:
NTLM
Kerberos
Schannel (disabled by default)

There is a'new' type to add to the list: "Starting with Windows Server 2008 R2 and Windows 7, the Negotiate 
Security Support Provider (SSP) supports an extension SSP, Negoexts.dll. This extension SSP is treated as an 
authentication protocol by the Windows operating system, and it supports SSPs from Microsoft, including 
PKU2U. You can also develop or add other SSPs."

Is this related to bug 7093? "win: windows 8 - allow 'microsoft login' type accounts (username contains  @)" - 
since PKU2U started in Windows 7 according to the online docs, probably not - but it does sound a but like 
it...

This doc makes it clearer - yes it is related:
"Extending Authentication Protocols
Windows 7 enhances the home and small network experience with a feature called Homegroup. Users can 
share data, such as media files, between computers in a home and use an online ID to authenticate between 
these computers. Users must explicitly link their Windows user account to an online ID in order for this 
functionality to work. Authentication is enabled by a new protocol called Public Key-based User to User or 
PKU2U.
Windows 7 also introduces an extension to the Negotiate authentication package, Spnego.dll. SpNego is the 
feature that decides which authentication protocol should be used when authenticating. Before Windows 7, it 
was typically a choice between Kerberos and NTLM (Windows Challenge/Response). The NegoEx extension is 
treated as an authentication protocol by Windows and it supports two Microsoft security support providers: 
PKU2U and Live. It's also extensible to allow for development of other security support providers.
Both of these features work when connecting to another computer in the Homegroup using an online ID. 
When one machine connects to another, the negotiate extension calls the PKU2U security support provider 
on the login computer. The PKU2U security support provider obtains a certificate from the certificate 
authority policy engine and exchanges the policy (along with other metadata) between the peer computers. 
When validated on the peer computer, the certificate is sent to the logon peer for validation, the user's 
certificate is mapped to a security token, and the logon process is completed."
https://technet.microsoft.com/en-us/library/2009.05.win7.aspx?f=255&MSPPError=-2147217396