In the current version of the OASIS ebXML Registry specification, there are no provisions for confidentiality of Registry content. All content submitted to the Registry may be discovered and read by any client - which means anybody can find out that an entity is accessible via the registry, and where their CPP is located.
On the other hand, only authorized submitters who have been authenticated using digital signatures can publish data in the registry. I am assuming that this means there exists a fine-grained mechanism whereby only the owner (or his agent) of information (e.g., the CPP) can submit or change his own information - as opposed to having to submit his information through a central authority for inclusion in the Registry. The CPP owner may have some means of obfuscating his own CPP, or parts thereof - revealing information only to authorized users- since the CPP itself could very well reside on his own server. Of course, I'm making a lot of assumptions. The details have to be ferreted out by the folks responsible for the working paper on "Discovery" of Healthcare CPPs: Peter Barry, Joe McVerry, and Dick Brooks! I think Joe only volunteered to look into UDDI. That leaves Peter and Dick to be the experts on the ebXML Registry. Maybe I could add Lisa Carnahan to the list, too. Does anyone else want to volunteer? William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 ----- Original Message ----- From: "Christopher J. Feahr, OD" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, 10 June, 2002 06:31 PM Subject: digital certificates for access to CPP repository Dear Group: I would like to know if we have agreement (or could agree) on the following requirements regarding access to the CPP registry/repository data: 1. Allow any party to access the CPP registry, thus obtaining the URL that points to an entity's "repository" record(s). 2. Require a standard mechanism for entrance to the CPP repository record that somehow looks for a valid digital ID certificate If every CPP repository user was required to have a valid ID certificate somewhere (e.g., the AMA/Verisign deal that was mentioned once) then requiring that certificate as the "entry pass" to the repository would seem to be a way to keep the riff-raff out. I think we may still need ways to individually [further] secure sections of the repository record, but would a dig. certificate be a reasonable way to secure the repository front door? My suggestion would be to include a data element in the repository (perhaps another URL) that pointed to a default "access denied" message created by the repository record owner. (I guess in the absence of an entity-specific "access denied" message that provided an alt. means like a cust. service phone #, the user would simply get a "page not found" error) More questions (assuming that we do want to secure the front door with a certificate): 1. How tough are these to obtain? Could Mr. Hacker apply for one and thereby have the keys to the kingdom? 2. Are there standard protocols (possibly in the ebXML CPP specifications) for implementing this type of auto-authentication when you attempt to access a URL? 3. How many data elements would be necessary in the repository record to handle auto-auth... and what would they be called? Regards, Chris Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
