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
