Joe, I understand. On the other hand, how else would you authentic an entity attempting to access a CPP reposistory? Furthermore, even assuming authentication, it's not at all clear to me that all entities would want their CPP info to be accessible to all parties accessing such a registry. This is a big can of worms and without any business case and business requirements, I believe that details of this type are much too premature.
My concern is about the complexity that is ensuing as a result of these discussions and that I don't believe this (CPP/A, registry, etc.) is at all essential for health care to achieve compliance with HIPAA by the various drop-dead dates. Rachel -----Original Message----- From: joe mcverry [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 11, 2002 9:42 PM To: [EMAIL PROTECTED] Cc: 'WEDi/SNIP ID & Routing' Subject: Re: digital certificates for access to CPP repository If authentication is in place then there should be no need to worry about "digital certificates for access to CPP repository." Rachel Foerster wrote: > > Oh Lordy, Lordy! Are we going down a rabbit hole with Alice or what! I > understand authentication is part of the CPA spec, but how is this relevant > to getting the industry up and running with EDI by the HIPAA compliance > dates? > > Rachel > > -----Original Message----- > From: joe mcverry [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, June 11, 2002 4:13 PM > To: WEDi/SNIP ID & Routing > Subject: Re: digital certificates for access to CPP repository > > Authentication has been addressed in several levels. For example a > snippet from the ebXML CPA documents reads > <quote> > 8.4.13.5 isAuthenticated attribute - > The isAuthenticated attribute has the possible values of "none", > "transient", "persistent", and > "persistent-and-transient". If this attribute is set to any value other > than "none", then the receiver > MUST be able to verify the identity of the sender. In general, transient > authentication can be > implemented using a secure transport protocol like SSL (with or without > the use of basic or > digest authentication); persistent authentication can be implemented > using a digital signature > mechanism. Secure transport information is further provided in the > TransportSender (see > Section 8.4.24) and TransportReceiver (see Section 8.4.32) elements > under the Transport > element. Persistent authentication information is further provided in > the SenderNonRepudiation > element under DocExchange/ebXMLSenderBinding (see Section 8.4.42) and > the > ReceiverNonRepudiation element (under DocExchange/ebXMLReceiverBinding > (see Section > 8.4.53). > > The CPA would be inconsistent if isAuthenticated is set to "transient" > or "persistent-and- > transient", while isSecureTransportRequired is set to "false". > > 8.4.13.6 isAuthorizationRequired attribute > The isAuthorizationRequired attribute is a Boolean with possible of > values of "true" and > "false". If the value is "true" then it indicates that the delivery > channel MUST specify that the > sender of the Message is to be authorized before delivery to the > application > </quote> > > Source: Collaboration-Protocol Profile and Agreement Specification > Version 1.11 > Author: OASIS ebXML Collaboration Protocol Profile and Agreement > Technical Committee > Date: April 4 2002 > URL: > http://www.oasis-open.org/committees/ebxml-cppa/documents/working_drafts/ebC > PP-1_11.pdf > > "William J. Kammerer" wrote: > > > > 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 > > -- > ----------- > Joe McVerry > American Coders Ltd. > POBox 97462 > Raleigh, NC 27624 USA > 919.846.2014 (voice/fax) > http://www.americancoders.com > Home Of OBOE - an EDI and EDI/XML Translator > and xBaseJ - xBase Database Engine For Java -- ----------- Joe McVerry American Coders Ltd. POBox 97462 Raleigh, NC 27624 USA 919.846.2014 (voice/fax) http://www.americancoders.com Home Of OBOE - an EDI and EDI/XML Translator and xBaseJ - xBase Database Engine For Java
