It took me a while to get my head around the new .NET Standard which is going to affect the monikers that are going to be used in ASP.NET Core.
I felt the need to simplify it as much as possible primarily to help me remember how it works :-)
Portable Class Libraries
The .NET Standard can be seen as the next version of portable class libraries (PCLs).
The main disadvantage of a PCL is that it is tied up front to one or more .NET platforms. You see the .Net platforms listed in the first column of the table below.
Imagine you create a PCL now and configure it to support Silverlight and .Net Framework 4.6. Then your class library will only support the cross section of the two platforms. And because Silverlight is selected not much API is left. It gets even worse if you add more .NET platforms.
Where .NET Standard comes in
.NET Standard is introduced to mitigate this problem. The standard has different versions. The higher the version number, the more .NET API you get. For example: the API in System.Net.Security is supported in version 1.3. If it's supported in 1.3 that means it's also supported by all versions after that. Version 1.0 has the smallest API possible.
Older or unsupported .Net platforms like Silverlight can only use the smallest possible .NET API, so version .Net Platform Standard 1.0. New platforms like .NET Core have support for the largest API possible, so the highest .NET Standard version, which includes the APIs defined in all previous versions of the standard.
Your class library targets a certain .NET Standard version and will work on all .NET platforms that support that .NET Standard version.
Enforcing the standard
The idea is that the API is enforced in tooling (like Visual Studio) by using reference assemblies also known as contracts which will not contain any implementation, but just the interface to the API.
With the standard in place parties (Microsoft, Mono team etc) will "just" have to implement these contracts to support a certain platform standard.