[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: composition of Issuer identifier (also: "dns-date" URN NID)
As far as identifiers go: 1) Allowing the optional use of a URI for anything that is potentially downloadable means that if an application wants to provide that feature they may. Thus allowing URLs as one form of assertion ID makes a lot of sense. 2) Where issuer IDs are concerned the 'issuer' is clearly not 'downloadable' but there might well be a need at some point to support some form of service that was resolved in some fashion from the Issuer ID. Here DNS names make a lot of sense since it is possible to map from a DNS name to a service of any type using an SRV record. DNS names also have a unique owner and there is a working consensus on a single name root so ambiguity between DNS names does not arise the same way that it can with X.400 names. I think that at this point we can pretty much assume DNS infrastructure as a given and ignore the claims of those who believe that X.500 is poised to replace it imminently. 3) The DNS-DATE URN scheme has come up many times in many forms. The earliest one in actual use being the Presidential Document Identifiers used by the Whiethouse Publications service in 1992. The observation is that ownership of a DNS name can be transfered. Therefore to 'fix' the semantics of the name it is necessary to extend the name with the date. Where the name relates to a message rather than an issuer it is necessary to have another field to distinguish between messages issued on the same day, so we end up with: [URN-Prefix] : [DNS-NAME] : [Date] : [Serial] A sinilar scheme may be found in implementations of the USENET system which is represented in the URI scheme as news:<message-id>, we also specified a msgid:<message-id> scheme at one time for mailing list messages (I can't remember if it got through to the final RFC). For both schemes the spec only requires that the message id contain the DNS name and the @ sign and that the message ID not be reused within 2 years. The intention of using a URN in the examples was simply to reinforce the fact that as with USENET the identifier was not a 'locator' it was a retrieval index. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Jeff Hodges [mailto:jhodges@oblix.com] > Sent: Tuesday, June 12, 2001 7:57 PM > To: oasis sstc > Subject: composition of Issuer identifier (also: "dns-date" URN NID) > > > 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-pa ram-00.txt ..that doc has some guidance relevant to some of the above. JeffH
Phillip Hallam-Baker (E-mail).vcf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC