RE: Message Service Specification Version 0.91, or PartyId revisi ted

["Burdett, David" <david.burdett@commerceone.com>]

William

See comments embedded below.

David

-----Original Message-----
From: William J. Kammerer [mailto:wkammerer@foresightcorp.com]
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:1.3.6.1.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"