NGWS SDK Documentation  

This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!

Overview of Shared Assembly Names

Part of an assembly's identity is a simple, friendly textual name (like My401kApp). These names are given to the assembly by the developer when the assembly is authored. These names are referred to as simple names. Simple names are not guaranteed to be unique - there is nothing in the tools or in the runtime to prevent collisions.

Simple names for assemblies are easy and convenient to use and are sufficient in a number of cases.  In particular, individual developers or small development shops have no need for a more sophisticated naming scheme and we shouldn't complicate their lives for no obvious benefit.  However, there are a number of situations where developers must be able to guarantee that the names they choose for their assemblies will be globally unique.  In COM, uniqueness was guaranteed by assigning a unique GUID to each component.  We are not carrying this notion forward into the runtime because GUIDs have a number of deficiencies that we would like to correct.  In particular, while GUIDs are unique when they are generated, nothing prevents another developer from later reusing your GUID and "substituting" her code for yours.

The runtime solves this problem of name uniqueness and name security using standard public-key cryptography.  Names secured with a key-pair are termed shared names.

In particular, shared names satisfy the following requirements:

  1. Shared names guarantee name uniqueness by relying on unique key-pairs
  2. Shared names prevent others from "taking over your namespace".  Because only you have your private key, no one can generate the same name that you can.  The 401k assembly generated with my public key has a different name than the 401k assembly generated with your private key.
  3. Shared names provide some notion of identity. If the runtime crypto checks pass, you can be guaranteed that the assembly comes from the person you thought it did (assuming his private key wasn't compromised, of course).  Note however that shared names in and of themselves do not provide a level of trust.  Trust is accomplished through full digital signatures complete with certificates.

In addition, the runtime's security team also has the following requirements for shared names:

  1. Shared names can not tie the runtime to using Authenticode technology
  2. Shared names can not require that only signed code can be granted permissions.  The security team is investigating several scenarios where it is useful to grant permissions to unsigned code.  For example, you may want to grant permissions to code that was retrieved through a secure channel.