[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-cppa] CPPA version 1.10
I agree regarding social security number. However Chris also mentioned taxpayer ID number. I believe that UDDI also provides for identification by taxpayer ID. For a business, that isn't a problem regarding SSN. Of course it raises an interesting question for individuals. Still, it would be up to an individual operating as a business to get a taxpayer ID that is not his/her social security number. Regards, Marty ************************************************************************************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* |---------+----------------------------> | | David Fischer | | | <david@drummondgr| | | oup.com> | | | | | | 03/15/2002 03:51 | | | PM | | | | |---------+----------------------------> >-------------------------------------------------------------------------------------------------------------------| | | | To: Christopher Ferris <chris.ferris@sun.com>, CPPA <ebxml-cppa@lists.oasis-open.org> | | cc: | | Subject: RE: [ebxml-cppa] CPPA version 1.10 | | | | | >-------------------------------------------------------------------------------------------------------------------| Chris, you are right on the mark. However, SSN is a bad example. The legislation which instituted these numbers specifically stated that they NOT be used as a universal identifying number -- even though they are used that way quite often, even by state governments. There are some privacy issues there which it would be best to avoid. I wonder if it would be better to focus (not exclusively) on something more global -- like UCC/GLN -- rather than DUNS. I absolutely agree though that there doesn't/shouldn't need to be any *single* central authority for the identifiers. I assume that SMEs will end up using eMail addresses as a start. Regards, David. -----Original Message----- From: Christopher Ferris [mailto:chris.ferris@sun.com] Sent: Friday, March 15, 2002 2:24 PM To: CPPA Subject: Re: [ebxml-cppa] CPPA version 1.10 Duane, Please see below. Chris Duane Nickull wrote: > Chris: > > If I thought that would solve the problem, I would have done this. The > problem is that a DUNS number is not as easy to get once you are outside > the confines of the US. That isn't the point. The point shouldn't be to identify a registry like DUNS that everyone can, should or must use, it should rather be to provide a means that an identifier can be used and mutually understood without requiring a centralized process or registry. A URI provides this capability, that is its purpose. If I had my druthers, I'd prefer to see that there were no 'type' attribute but that the value be required to be a URI. More below. > > I agree that we cannot close the list. Here is a copy of the email I > sent to Dale (Sorry - meant to copy the list): > > ******* MESSAGE ************ > Dale: > > Here are the requirements for this artifact: > > 1. It can globally, uniquely identify a company why limit to a company? > 2. It is available to any company (worldwide) without unreasonable > overhead. agreed. > 3. Sub-groups within a company MAY need to uniquely identify themselves > as a subgroup but within the domain of the company. agreed. > > On the wish list: > > 4. It can be used to get more definitive information about a company. > > I think that URI meets all of the requirements and I would be happy for > now. Dun and Bradstreets numbers are not easy to acquire globally, > therefore are not as desirable for non-USA companies. DUNS is nice > though becuase it says that the company has undergone some sort of > screening process but that would only be useful if there was a way to > verify that the DUNS number was legitimately issued, which there is not > (not without manual intervention.). > > Other items like tax id numbers may be used (need to clarify if they are > globally unique if used with a country qualifier) or a unique number > registered with a global authority like IANA. Or just an adopted URN namespace e.g. urn:www.ssa.gov:ein:123456789 or urn:www.ssa.gov:ssn:123456789. The namespace becomes the qualifier for the raw ssn or ein number which is managed by the authority that owns the URN namespace (in this case, the entity www.ssa.gov which is the US Social Security Administration). (note that I'm unclear as to whether the SSA assigns EINs or if this is maybe a function of the IRS) The whole point here is that there not need to be a *single* central authority for the identifiers, but that those authorities that are already in place merely ask for a URN namespace that can be applied to their existing identifiers so as to fully qualify them so that it can be globally recognized and we can end this never-ending debate (which has resurfaced more times in the context of ebXML than I care to recall!) > > Duane > > ***************************** > > I have no other ideas off the top of my head. I am glad everyone at > least agrees this is a problem. > > Duane > > Christopher Ferris wrote: > >>Duane, >> >>Sure, we could define an enumeration that included >>DUNS, but there are many others out there. If the >>enumeration is used, then it is effectively a closed list and only the >>owners of the schema can extend to add other namespaces. >>This approach seems to me to be quite unnecessarily constraining. >> >>Why don't you lobby D&B to get (or publicly declare) a >>namespace identifier. This has only been an issue for >>I don't know how long. Seems to me that the UN could >>excersize some of its clout to encourage D&B to help >>with this problem. >> >>Just establishing a closed enumeration is NOT IMO >>a viable solution to this issue and I won't support >>it if we choose this route. >> >>Cheers, >> >>Chris >> >>Duane Nickull wrote: >> >> >>>>Tony Weida wrote: >>>> >>>>CPPA version 1.10 is attached. >>>> >>>> >>>Tony and all: >>> >>>Until the issue of PartyID attribute "type" is resolved, I wil not >>>support this document. I wish to suggest the changes. >>> >>>Currently you have: >>> >>><element name="PartyId"> >>> <complexType> >>> <simpleContent> >>> <extension base="tns:non-empty-string"> >>> <attribute name="type" type="tns:non-empty-string"/> >>> </extension> >>> </simpleContent> >>> </complexType> >>></element> >>> >>>There has to be somthing sematically meaningful for this to be a party >>>identifier. For now, I suggest the following: >>> >>>Change the attribute content model to an enumerated list of >>> >>>( DUNS | URL | ... ) >>> >>>and allow companies to chose one of several types of PartyID's that are >>>guaranteed to be unique. If DUNS is guaranteed unique, then it can be >>>used but you must specify the semantics of DUNS somewhere. I suggest >>>you put this in the specification that governs this schema. Clearly >>>state that " a value of "DUNS" indicates the Dun and Bradstreets >>>identification number of the company as given by ...". Make the same >>>type of statement for any other unique identifiers types you allow int >>>he enumerated list. For instance, "URL is instance value of a properly >>>formed URL owned by the Trading Partner.." >>> >>>Otherwise, this is completely useless and will not meet the >>>requirements of CPPA. >>> >>>Please give this some serious thought. We can always expand the >>>enumerated list later based on requirements of companies. >>> >>>Duane Nickull >>> >>> > ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC