composition of Issuer identifier (also: "dns-date" URN NID)

[Jeff Hodges <jhodges@oblix.com>]

In..

  composition of AssertionID (Issue: DS-4-04: URIs for Assertion IDs) 
  http://lists.oasis-open.org/archives/security-services/200106/msg00025.html

..the composition of Issuer is punted.. 

> D2. some-issuer-identifier -- should this simply be a DNS 
> fully-qualified-domain-name? Should it be a URN [6]? Should it be something 
> else?

Given some further thinking about it in..

  URIs as general-purpose identifiers, and identifiers in general 
  http://lists.oasis-open.org/archives/security-services/200106/msg00074.html

..it seems to me that simply using an otherwise unadorned, "absolute" DNS
domain name (see RFC1034; aka a "Fully-Qualified [DNS] Domain Name", aka a
"FQDN") will satisfy SAML's needs for identifying an Issuer. e.g...

  <Issuer>example.com</Issuer>

..or even..

  <Issuer>securitydomain.in-house.example.com</Issuer>

..or even..

  <Issuer>I.Issue.SAML.assertions.example.com</Issuer>



I note that in draft-sst-core-phill-07 and list discussions thereof, Phill
showing URNs used to identify Issuers, e.g...

  URN:dns-date:www.bizexchange.test:2001-01-03:19283

Note that this URN is pre-supposing a URN Namespace Identifier (NID) of
"dns-date", and is thus assuming that there is at least some notion of the
syntax and semantics of identifiers minted within that URN namespace, and that
it is written down somewhere. However, I haven't found any such information in
enqueued NID proposal docs, approved NID docs, or any of the mailing lists I'm
monitoring. 

If we were to use a URN-based identifier as-illustrated in
draft-sst-core-phill-07 et al, we should either use an established URN
namespace with documented syntax and semantics, or we would have to create one
and design & document & register it. For instance, in fully examining the
example URN above, one needs to know what the semantics of the "date" portion
are, and what those of the trailing "19283" numeric string are. 

By using simply an unadorned absolute DNS domain name we avoid most of those
issues, and entirely avoid the need to register anything having to do with
these identifiers. Now, deployers WILL be able to "play games" with even DNS
domain names as hinted at in the "<Issuer>" examples above. And we will have to
define nominally what it means when the DNS domain name isn't dereferenceable
(via the DNS of course), and when it (or some subportion thereof) is
dereferenceable. 

It is worthwhile to note that others have been thinking about the operational
considerations of using DNS domain names (and URIs) as identifiers..

[18] Considerations for URI and FQDN Protocol Parameters
http://www.ietf.org/internet-drafts/draft-eastlake-uri-fqdn-param-00.txt

..that doc has some guidance relevant to some of the above. 


JeffH