bdxr — archive

SMP and Extensions

From: Sven Rasmussen
To: [email protected]
Date: Wed, 30 Sep 2015 11:57:00 -0000

Dear all I have recieved the following question for clarification regarding use of extensions to the SMP datamodel. I propose to discuss this in our meeting today if possible. Best Regards Sven Fra: Massimiliano Masi < [email protected] > Dato: fredag den 11. september 2015 kl. 12.01 Til: Sven Rasmussen < [email protected] >, João Gonçalves < [email protected] >, Uwe Roth < [email protected] > Emne: SMP and Extensions Hello Sven, I hope this mail finds you well! Together with Joao and Uwe from the OpenNCP team, we’re trying to use the SMP and SML building blocks from e-SENS in the eHealth domain. At the moment eHealth corner 2 and 3 (named National Contact Points, NCPs) they are configuring themselves by using a Trusted Service List, TSL, highly inspired as ETSI TS 102 231. Unfortunately this approach has some drawbacks which we would like to overcome by using SML+SMP. Due to the very similar structure, a mapping amongst TSL and SignedServiceMetadata can be done (as shown in the attached document). We also tried to use SMP to publish information related to an XML configuration of the NCP, named the International Search Mask, ISM. The ISM is a simple XML containing the values needed by the various member states to identify a patient (e.g., name, social security number, etc). We planned to exchange this value as smp:Extension, so each remote OpenNCP can auto-configure itself by looking at that record. This should be the proposed mapping: JA X-NONE EHealth portals use an adaptive Internation Search Mask configuration to switch the presentation of the portal for the specific patient's country. Process Opt Usage Convention ProcessIdentifier R MUST contain "urn:ehealth:ncp:<country>:ism" ProcessIdentifier/@Scheme R MUST be urn:ehealth:smp:scheme:proc_id ServiceEndpointList R Endpoint/@transportProfile R MUST be "urn:ehealth:transport:none" EndpointURI X RequireBusinessLevelSignature X ServiceActivationDate R MUST contains the Date when the mask has been issued ServiceExpirationDate O MUST contains the Date when the service will be stopped Certificate X ServiceDescription O MAY contain the english description of the search mask TechnicalContactURL O MAY contain the information related to the technical contact TechnicalInformationURL O MAY contain the URL pointer to the remote mask technical description Extension R MUST contain the international search mask XML as direct children However, Joao noticed that in section 2.3.2 of SMP, it is stated: SMP publishing services MUST NOT produce metadata that contain extensions necessary for a Client to understand in order to make use of this metadata. The ability to parse and adjust client behavior based on an extension element MUST NOT be a prerequisite for a client to locate a service, or to make a successful request at the referenced service. This sentence seems to hinder us to use the Extension element as we planned. In fact, we thought that the semantics of the Extension element are to be established by agreements amongst the provider and the consumer. I think that the usage of extensions should be discouraged by the standard, but the MUST NOT keyword seems to really restrict its usage. A MAY NOT would somehow still restrict the usage of Extensions yet allowing the SMP to be operated in other domains. What do you think? -- Massimiliano Masi, http://www.mascanc.net Tiani ``Spirit'' GmbH Guglgasse 6 Gasometer A 1110 Vienna Austria/Europe <SMP-TRUST.docx>