[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Message Service Specification Version 0.91, or PartyId revisi ted
William See comments embedded below. David -----Original Message----- From: William J. Kammerer [mailto:firstname.lastname@example.org] Sent: Friday, January 05, 2001 6:40 AM To: ebXML Transport (E-mail) Subject: RE: Message Service Specification Version 0.91, or PartyId revisited Thanks to David Burdett, Christopher Ferris and Michael Mealling for their comments on PartyId nomenclature based on the ITU-T Rec. X.660 OID URN. David's problem "with using DUNS is that they are not Global." But it doesn't matter what is used to identify a party, as long as it uniquely identifies that party. For companies in Japan, perhaps they're used to using the EAN Location Number, which satisfies this criteria of uniqueness. There's no need for a common identification scheme; RosettaNet has fixated on the DUNS in the belief that standardizing PartyID will give fewer options for people to mess up - we don't have that design constraint. <DB>I agree, but if DUNS and EAN each allocate the number 123456789, but to different organizations, then there is confusion. You therefore need to add a prefix such as DUNS or EAN to make it clear. But just suppose decided to use DUNS to represent "David's unique numbering scheme" and I allocated 123456789, then there is still confusion unless there is a registry we can use that stops me. We **need** that registry, the id is only unique within a domain.</DB> Not only must the ID be unique, but it should have someone important enough to vouch for that particular ID, as in signing a certificate extension for that unique ID. A normalized and canonical method of identifying the authority <DB>Identifying the authority is the crux of the problem. We need to specify what it is.</DB> - perhaps by using URNs based on the OID or a URN namespace - is needed to make automatic processing of certificates possible. The EAN presumably knows their members well enough to vouch for them; likewise, S.W.I.F.T. might take it upon themselves to sign certificate extensions for banks using the BIC. I just want to make sure that when I think I'm talking to the company purporting to hold a particular DUNS no., or a carrier purporting to be a particular SCAC, that somebody up the food chain whom I trust has vetted their certificate. It doesn't matter that there might be three or four possible URN prefixes that are used to identify a DUNS no. - perhaps "urn:oid:18.104.22.168.4.1.519.1.", or "urn:oid:1.3.60." or even "urn:duns". Dun & Bradstreet would recognize its own namespaces and OIDs, and be willing to sign any number of extensions with the variants used to specify the naming authority, assuming the certificate really belongs to the owner of the target D-U-N-S. Likewise, the CPP/CPA, as Chris alluded to, can hold all possibilities of variants that the TP prefers to be named by, just as in the UDDI identifierBag. Michael Mealling has said that he wouldn't be surprised if Dun & Bradstreet is assigned one of the inaugural URN namespaces. That's great; but not everybody will choose to use a DUNS - there are EAN location numbers, SCACs, BICs, UCS IDs, and on and on. In the meantime, when people wish to identify the naming authority, we can't be held up waiting for that authority to check out a namespace with the IANA. <DB>I don't think this will be necessary. Usually organizations discover the ids of their partners from those partners, or alternatively from registries of ids such as Dun & Bradstreet or EAN. Generally these sources are trusted, so you don't need to check the authority separately</DB> Under no circumstances do we want to burden ebXML with any responsibility for ID registration; that's completely unnecessary anyway considering there are a surfeit of recognizable IDs that any one entity possesses. <DB>I completely agree</DB> Chris talked about resolution services for URNs, which might be nice but hardly necessary. Finding where your trading partner is (e.g., TCP/IP address) is a different problem than making sure that a guy purporting to be Proctor & Gamble really is, rather than some 15 year old in his bedroom. <DB>I think we need to separate registration of ids with an authority, from the use of signatures to validate the autyhenticity of a sender</DB> More likely than not, I'm dealing with known trading partners, as opposed to "discovering" who can sell me detergent based on SIC code. But even when I've found my known trading partner in the registry (whether UDDI or ebXML's), I want to make sure that all the information I get from that registry is really for Proctor & Gamble. I think I'd be willing to trust a Verisign Type 3 certificate altogether, or a certificate extension signed by the Uniform Code Council vouching for the (known) EAN/UCC location ID. My ignorance of X.509 certificates might be showing, but my main point is 1) I'm not necessarily using the PartyId to "locate" my partner's port (though in effect, that's what a VAN, or a VAN-lookalike like Viacore, would be doing for me), 2) I'll use whatever ID my partner wants me to refer to him by, and 3) I want somebody important, perhaps the naming authority who gave him that ID, to say that the ID is really his (before I trust the rest of the information, including the TCP/IP address or URL and contact addresses, in the registry). William J. Kammerer FORESIGHT Corp. 4950 Blazer Memorial Pkwy. Dublin, OH USA 43017-3305 +1 614 791-1600 Visit FORESIGHT Corp. at http://www.foresightcorp.com/ "Commerce for a New World"
Powered by eList eXpress LLC