Hi (there is tl;dr at the end). When an NSA retrieves a topology, it has to ensure that the topology does not overwrite any existing topology entities - either accidentally or by purposely injecting identifiers to overwrite topology entities from other topologies (id clash). This is an important issue as soon as an NSA dynamically retrieves topologies, as they can no longer be manually verified. The identifier used in NML is the id attribute of XML elements, has the following structure: urn:ogf:network:nordu.net:2013:opaque Such a URN can (roughly) be split into three parts: 1: urn:ogf:network 2: nordu.net:2013 3: opaque For more details on the URN construction see GFD.202. One is not allowed to interpret URNs as such, however I believe this is concerns the opaque part. The first part is static, and we can largely ignore it here. However the second part (called ORGID in GFD.202 is very important). It is composed of two parts, a domain name, and a year (can be also year+month, or year+month+day). In order to prevent injection/override of topology entities, an NSA should only be allowed to create ids that fit its organization and relevant domain names. I.e., only NORDUnet should be allowed to publish identifiers with the nordu.net domain name (which NORDUnet of course owns). To integrate with existing security infrastructure this means matching the host name in the X509. Furthermore regular URL - certificate matching still applies. Say I publish a topology in the following URL: https://nsi.nordu.net:9443/NSI/topology/nordu.net:2013.xml The host name in the URL is "nsi.nordu.net" and hence the host name in certificate must be "nsi.nordu.net" as well. Furthermore the topology entities represented in the resource, must match with the certificate name, i.e., they should start with urn:ogf:network:nsi.nordu.net:. Right now this is not the case, it uses "nordu.net". This is actually an injection, but not a serious one. It is possible to create some complicated rules to allow such a case, however I strongly suggest going for simplicity and enforcing a strong 1:1 correspondence. Similarly, the NSA urn id, must also adhere to this principle. This, unfortunately, makes it impossible to host an NSA for which the identity does not fit the certificate host name. For the date part, extending the certificate part to hold for this is bit tricky. If I use "2013", my certificate should of course be valid for some range of the year 2013. However certificates have a limited lifetime, and are usually only valid for 1-3 years. Once the certificate have rolled over, it is no longer valid for any date in 2013, and hence the year part can no longer be verified. A somewhat weird solution for this could be to keep the old certificate and present it with the topology, however all security stacks will (and should) reject such a certificate. It is possible to the check manually of course, but this impractical, and a very bad idea. I cannot see any practical way to validate the years in URNs, meaning they do not really add any value for separating identifiers. Summary: 1: The domain name in a NML topology id URNs must match the X509 host name A. This must hold for the NSA URN as well. 2: There is no practical way to enforce the year/date segment. As a corollary of 1A, a single endpoint cannot host an NSA for an alternative domain, without coming up with a rather convoluted security model. -- Some further questions for the GFD.202 authors: URNs are supposed to be persistent. Host names are not persistent. Why put them in there? URNs are supposed to be location independent. Why put host names in there? Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet