The purpose of this document is to specify the web service interface provided by the national document sharing service (DDS) for data retrieval.
In the document the concepts of authorization and authorized are used primarily in a security context, that is, in the understanding that a person or a system is authorized to use a given resource. If the concepts concern health professionals with Danish authorization listed in Danish Health Authority’s authorization register, it will be stated explicitly.
A system that uses the web service(s) described in this document is referred to as a user system. Note that there are particular responsibilities that the user system must fulfil, as described in section 1.5.
It is assumed that the reader understands the general use of SOAP-based Web services, why technical terms such as SOAP, WSDL etc. is not clarified. Knowing Den Gode Webservice (DGWS) 1.0.1 described in [DGWS 1.0] and [DGWS 1.0.1] will facilitate comprehension considerably.
It is also assumed that the reader understands the use of IHE XDS.
Version | Date | Responsible | Description |
---|---|---|---|
0.1 | 14.1.2013 | Systematic | Initial version |
0.9 | 27.2.2013 | Systematic | Prepared for testing in the demonstration project |
0.9a | 18.4.2013 | Systematic | SystemOwnerName corrected in section 4.1.1 |
1.0 | 19.6.2013 | Systematic | Quality assured |
1.1 | 28.11.2014 | Systematic | National Patient Index (NPI) replaced with Document Sharing Service (DDS) |
1.2 | 05.05.2015 | Systematic | Code references has been updated due to name change from NPI to DDS |
1.3 | 09.09.2016 | Systematic | Changed nsi:skscode to nsi:skskode and nsi:sorcode to nsi:sor to fit XML schema |
1.4 | 21.09.2016 | Systematic | Added details for user relation in HSUID |
1.5 | 10.11.2016 | Systematic | Added description of level 4 authentication required for healthcare professional user type, added missing error internal_error_treatmentrelation. |
1.6 | 17.12.2016 | Systematic | Added legal values for CitizenUserRelation in section 4.1.1. Updated examples in section 7. WSDL URL updated in section 7 |
1.7 | 08.02.2017 | Systematic | Enforcement of level 4 authentication modified to level 3 for healthcare professional user type. |
The purpose of this section is to provide an overview of the definitions and document references used in this document.
Definition | Description |
---|---|
DDS | Document Sharing Service |
IHE | Integrating the Healthcare Enterprise |
NSI | National eHealth Authority |
NSP | National Service Platform (within health care) |
SHAK | Hospital Department Classification |
SOR | Health service organization register |
STS | Security Token Service |
XDS | Cross-Enterprise Document Sharing |
The web service that is the subject of this document performs checks on consent as required by Health Act §42a, paragraph 6 and 7, unless consent override is applied (§42a, paragraph 5).
In addition, concerning the user's access to data, there may be aspects of complying with Health Act §42a that the web service does not have the ability to control, including the necessity of access to the information and the hospital management's authorization of non-authorized healthcare professionals. Consequently, agreements must be made between the data controller for document sharing service and the user system to establish the user system's responsibility in regard to compliance of Health Act §42a and additional IT security laws and regulations.
DDS Registry performs the role of Document Registry [ITI TF-1] and keeps and maintains metadata for registered documents [ITI TF-1]. DDS Registry does not perform the role of a Document Repository [ITI TF-1]. This role is performed by the source systems that register documents in DDS Registry.
A user system appears in the role of Document Source Actor [ITI TF-1] and can perform queries in the DDS Registry and find document metadata registered for patients. This scenario corresponds to ITI-18 [ITI TF-2b]. Subsequently, the user system is able to extract, i.e. retrieve, documents by means of the found metadata. This corresponds to IHE’s ITI-43 [ITI TF-2b].
For the usage scenarios described in the following, it is the responsibility of the user system to verify the information given as input. This includes information on the user context, and, for instance, any relation between a citizen user and the patient.
A user system performs retrieve of one or more documents by using the web service DDSRepository and operation DocumentRepository_RetrieveDocumentSet.
As input to this operation, the document id and other attributes found in document metadata returned upon querying the DDS Registry is used.
What is returned from the DDSRepository when retrieving documents depends on the user type.
If the user is the citizen him or herself, all documents are returned. A citizen user is also able to query another citizen's documents if the user has a relation to the citizen in question.
If the user is a health professional, consent checking influence what is returned as follows: when identified as a health professional for which patient consent blocks access, documents and document parts, respectively, covered by the consent, are filtered out of the reply and a mark is added indicating that filtering has occurred due to consent-related restrictions.
Note that general consents towards a health professional are always verified, while verification of data-specific consents would have to occur in the underlying document source. To which extent and how data-specific consents are verified depends on the specific document source and should be found in its documentation.
In addition, verification of the current treatment relationship between the health professional and citizen is initiated.
Forced extraction of documents is extractions that are performed using the consent override rule in the Health Acts §42a paragraph 5.
A user system performs forced extraction of documents registered in DDS Registry concerning a citizen by using the Web service DDSRepository and the operation RegistryStoredQuery where, as described in section 4.1.2, the use of consent override is indicated.
It is the responsibility of the user system to verify that the user is a health professional authorized to perform consent overriding.
Every third DDS Repository Web service is described in a separate section. The following template is used to document the exposed operations
Name: <operation header> | |
---|---|
Description: | Description of the function's purpose. |
Input: | Input parameters. |
Output: | Output parameters. |
Error handling: | Description of error handling, typically referring to the general description of error handling in (section 4.7). |
Roles: | Description of the required roles. |
Prerequisites: | Description of prerequisites that must be met for the function to complete successfully. |
Web service that expose operations for retrieval of documents based on metadata information concerning citizen in DDS Registry.
Name: DocumentRepository_RetrieveDocumentSet | |
---|---|
Description: | Extracts one or more documents based on document metadata. (The interface supports extraction of more documents, but in practice only one document can be extracted at a time with the current operating configuration) |
Input: | RetrieveDocumentSetRequestType with structure as described for IHE XDS Retrieve Document Set in [ITI TF-2b] section 3.43. Note that for a user who is health professional, additional information concerning data treatment must be provided in the header as described in section 4.1.2. |
Output: | RetrieveDocumentSetResponseType with structure as described for IHE XDS Retrieve Document Set in [ITI TF-2b] section 3.43. A collection of one or more documents with associated metadata. In the case where one or more documents are found for which a user, who is a health professional, does not have access, a warning is returned as described in section 0. |
Error handling: | See section 4.7. |
Roles: | Health professional, Citizen |
Prerequisites: | Both user system and user must be authenticated and authorized as described in section 4.2.1. |
The Web service expects SOAP messages, where the SOAP header contains security header and MEDCOM header as required by DGWS 1.0.1, in addition to a Healthcare Service User Identification (HSUID) header.
Figure 1 SOAP message containing security header, MEDCOM header and HSUID header is used as message format.
The format of Security- MEDCOM and header are described in [DGWS 1.0] and [DGWS 1.0.1], while the format of the header HSUID described in [HSUID-header].
SOAP body contains IHE Retrieve Document Set RetrieveDocumentSetRequestType and RetrieveDocumentSetResponseType in request and response respectively. IHE Retrieve Document Set is described in [ITI TF-2b] section 3.43.
Borgere kan forespørge på egne eller anden borgers dokumenter ved at medsende OIO IDWS token. I dette tilfælde ser en request således ud:
When the user of the service is a citizen, attributes in Table 1 are applied in the HSUID-header.
The element Attribute | Sub-element | |
---|---|---|
Name-attribute | NameFormat-attribute | - |
nsi:UserType | nsi:Citizen | |
nsi:ActingUserCivilRegistrationNumber | Citizen's social security number | |
nsi:SystemOwnerName | Name of the system-owner of user system | |
nsi:SystemName | Name of user system | |
nsi:SystemVersion | Version of user system | |
nsi:OrgResponsibleName | Name of the organization responsible for user system | |
nsi:CitizenCivilRegistrationNumber | Social security number for citizen who is the subject of document(s) | |
nsi:CitizenUserRelation | Relation between the user citizen and the patient being queried. |
Table 1 Attributes in HSUID-header applied for user who is a citizen.
Note that it is the user system's responsibility to ensure that the social security number given in nsi:CitizenCivilRegistrationNumber is identical to the one used when querying for document metadata.
When the user of the service is a health professional, attributes in Table 2 are applied in the HSUID-header.
The element Attribute | Sub-element | |
---|---|---|
Name-attribute | NameFormat-attribute | - |
nsi:UserType | nsi:HealthcareProfessional | |
nsi:ActingUserCivilRegistrationNumber | Health professional's social security number | |
nsi:OrgUsingID | nsi:sor | Identification of the organization a health professional as user is associated. |
nsi:ResponsibleUserCivilRegistrationNumber | Social security number of the health professional under whose responsibility the user acts. | |
nsi:ResponsibleUserAuthorizationCode | Authorization number listed in the National Board of Health authorization register for the health professional under whose responsibility the user acts. | |
nsi:ConsentOverride | The value true indicates that consent overriding is applied. The value false indicates that consent overriding is not applied. | |
nsi:SystemOwnerName | Name of the system-owner of the user system | |
nsi:SystemName | Name of the user system | |
nsi:SystemVersion | Version of the user system | |
nsi:OrgResponsibleName | Name of the organization responsible for operation of the user system. | |
nsi:CitizenCivilRegistrationNumber | Social security number for citizen who is the subject of document(s) |
Table 2 Attributes in the HSUID-header applied for user who is health professional.
The identification of the organization of which the user is associated, may be given by a single value and a single format, such as SHAK-code:
<hsuid:Attribute Name="nsi:OrgUsingID" NameFormat="nsi:skskode">
<hsuid:AttributeValue>6620151</hsuid:AttributeValue>
</hsuid:Attribute>
The organization of which the user is associated, can alternatively be specified by two values, e.g. as both SOR- and SHAK-code:
<hsuid:Attribute Name="nsi:OrgUsingID" NameFormat="nsi:sor">
<hsuid:AttributeValue>440081000016006</hsuid:AttributeValue>
</hsuid:Attribute>
<hsuid:Attribute Name="nsi:OrgUsingID" NameFormat="nsi:skskode">
<hsuid:AttributeValue>6620151</hsuid:AttributeValue>
</hsuid:Attribute>
Note that it is the user systems responsibility to ensure:
The security of this Web service is based on the SOSI integration pattern in Den Gode Webservice (DGWS). Authentication is carried out by a trusted third party component on NSP (Security Token Service) and based on OCES digital certificates.
As a rule, the service requires authentication with the STS component based on employee signature (MOCES) corresponding to authentication level 4 for use by health professional users.
Highly trusted systems - initially the Health journal only - can during a transitional period gain access with level 3 based on company signature (VOCES).
The service enforces authentication level 3 for use by either user types.
Additional security aspects, including authorization, integrity, confidentiality, availability and privacy considerations are enforced to some extent by the technical service. The aspects that are not currently handled by the technical service will be handled in the service agreement, as specified by the data responsible authority (NSI), which users of the service must agree to.
Som en alternativ snitflade udbydes en OIO IDWS baseret snitflade for borgerforespørgler. Det medsendte OIO IDWS token validers af servicen.
When STS' signature of the ID card or OIO IDWS token is validated successfully, the user has been authenticated.
Authorization of user system is performed using a whitelist in the Web service based on information in the system-part of the ID card.
When the user system is authenticated and authorized, the user is authenticated by the HSUID header attribute nsi:ActingUserCivilRegistrationNumber.
For user of type health professional, it is verified that the authentication level of the ID card is equal or above 3, corresponding to consumer's use of a company certificate (Danish: Virksomhedscertifikat, VOCES) or a functional certificate (Danish: Funktionscertifikat, FOCES). When an ID card of level 4 is used, corresponding to an employee certificate, it is verified that the acting user ID provided in the HSUID header is identical to the user identified in the ID card.
Whether user is a health professional or citizen is determined from the HSUID-header-attribute nsi:UserType.
The Web service authorizes all users who are health professionals to use its operations.
A citizen is authorized when he/she performs queries for own documents. Therefore it is verified that the HSUID header describes the user as the same person as the one indicated as patient in the HSUID-header.
A citizen is, however, authorized to perform queries for another citizen's documents provided that the user citizen has a relation to the citizen being queried. As previously noted, it is the responsibility of the user system invoking the web service operation, to ascertain that such relation exists and that the user is indeed allowed to perform the operation.
A request with ID card is rejected when it has been more than 24 hours since the start of the ID card validity period.
As required by DGWS 1.0.1, only HTTP-status codes 200 and 500 are used.
On HTTP-status code 200, FlowStatus is always flow_finalized_succesfully.
Timeout on Web service operations is the same as default timeout on the NSP platform.
Each request is handled in its own session.
No check is performed whether MessageID in request has been received previously and no answer is guaranteed if a request with the same MessageID is received.
This deviates from DGWS 1.0.1 in regard to handling of retransmission.
If the request contains a flow ID, it is reused in the reply and calls to other services. If no flow id is provided, a unique flow ID will be created.
Handling of flow ID complies with DGWS 1.0.1.
Digital signing of replies is not supported. On request for non-repudiation, a fault-error message is returned as described in [DGWS 1.0].
Errors are handled in two ways, depending on their relation to the IHE standard. For errors related to processing of document ID and other things in from extraction input, errors are embedded in the response as described in section 4.7.2. For errors in general, such as errors related to security, SOAP errors are returned as described in section 4.7.1. Excluded from this distinction is, however, the warnings that are embedded in the response due to the withheld information caused by consents. These are described in section 4.7.2.
SOAP errors are returned with the components as described hereinafter. A structure has been chosen wherein both standard error codes as described in [DGWS 1.0] and Web service specific error codes can be returned.
<soap:Body> <soap:Fault> <soap:Code> <soap:Value>soap:Sender</soap:Value> </soap:Code> <soap:Reason> <soap:Text xml:lang="en">SAML Assertion has expired</soap:Text> </soap:Reason> <soap:Detail> <FaultCode xmlns="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd">expired_idcard</FaultCode> </soap:Detail> </soap:Fault> </soap:Body> |
Code listing 1 Structure of SOAP faults returned from Web service operation. The example shows FaultCode used when the ID card has expired.
For all Web service operations described in section 3 will be used SOAP Fault with FaultCode-values as listed in Table 3, originating from DGWS 1.0.1.
FaultCode | Description |
---|---|
missing_required_header | One or more mandatory DGWS headers are missing in the enclosed message, for example ID card, which always must be provided. |
security_level_failed | Authentication or authorization error. Invalid choice of security level. |
invalid_idcard | Authentication or authorization error. Error in SOSI ID card. |
invalid_certificate | Authentication or authorization error. Certificate is not OCES or expired. |
expired_idcard | Authentication or authorization error. SOSI ID expired or too old for this Web service provider. |
not_authorized | User has insufficient rights to perform the Web service operation call. |
nonrepudiation_not_supported | Web service provider system cannot provide a digital signature on the reply. |
Table 3 Applied FaultCode-values originating from DGWS 1.0.1
Additionally, Web service specific FaultCode-values as listed in Table 4 are used.
FaultCode | Description |
---|---|
invalid_hsuid_header | The message contains HSUID header with structural errors, missing content or invalid combination of content. |
invalid_date_timezone | An attached date has invalid format, cf. DGWS 1.0.1.All dates must be in UTC-time (Zulu). |
internal_error_consent | Authentication or authorization error. Server could not forward request. |
invalid_consent_data | Authentication or authorization error. One of the values used for authorization is not correct. |
internal_error_documentrepository | Server could not forward request. |
internal_error_treatmentrelation | Server could perform treatment relation handling (by invoking the treatment relation service). |
patient_id_missing | Patient ID missing in SOAP body part of request. |
invalid_autorisationcode | Authentication or authorization error. One of the values used for authorization is either empty or the health professional was not found in the database. |
Table 4 Applied Web service specific FaultCode-values
In WSDL, which describes the Web service(s) described in this document, these SOAP Fault status codes are not specified for every service (or operation).
See [ITI TF-2b] section 3.43.4.2 and 3.43.5 for description of embedding of errors in reply in addition to [ITI TF-3] section 4.1.13 for specific errors.
The following subsections describe the error codes and warnings embedded in the reply that are not defined in the IHE.
For a user who is a health professional, there may be registered consents for a citizen which prevents the user from accessing complete documents or parts thereof concerning the citizen (without consent overriding).
If complete documents or parts thereof are detained in the reply to a DDS Repository extraction due to consent towards the user, it is indicated in the reply by the following RegistryError element in the reply's RegistryErrorList element:
<rs:RegistryError codeContext="urn:dk:nsi:ConsentFilterApplied" errorCode="XDSRegistryError" severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"/> |
The namespace-prefix for "urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0", in this case rs, may have another value.
The Service endpoint, from which the document is extracted, is resolved based on HomeCommunityId or RepositoryUniqueId [ITI TF-2b]. If this endpoint does not return a useful reply or does not reply at all, it is indicated in the reply by the following RegistryError element in the reply’s RegistryErrorList element:
<rs:RegistryError codeContext="Responding gateway identified by Home Community Id: 1.2.3.4.5.6.8.10 and Repository Unique Id: 1.2.3.4.5.6.8.10 could not be contacted." errorCode="XDSUnavailableCommunity" severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error" location="DOCUMENT_UNIQUE_ID" /> |
The namespace-prefix for “urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0”, in this case rs, may have another value.
The Service endpoint from which the document is extracted is resolved based on HomeCommunityId or RepositoryUniqueId [ITI TF-2b]. If this endpoint is not registered, it is indicated in the reply by the following RegistryError element in the reply’s RegistryErrorList element:
<rs:RegistryError codeContext="Responding gateway identified by Repository Unique Id: 1.2.3.4.5.6.8.10 could not be found." errorCode="XDSUnavailableCommunity" severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error" location="DOCUMENT_UNIQUE_ID" /> |
The namespace-prefix for “urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0”, in this case rs, may have another value.
For a user who is a health professional, there may be registered consents for a citizen which prevents the user from accessing complete documents or parts thereof concerning the citizen (without consent overriding).
If errors occur while detaining complete documents or parts thereof from a DDS Repository extraction due to consent towards the user, the document or document parts are withheld. This is indicated in the reply by the following RegistryError element in the reply's RegistryErrorList element:
<rs:RepositoryError codeContext="urn:dk:nsi:Information Withheld due to Extraction Error" errorCode="XDSRepositoryError" severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"/> |
The namespace-prefix for "urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0", in this case rs, may have another value.
For DGWS It is validated that:
For OIO IDWS valideres det:
There will be performed:
DDS Repository Web service interface is based on the following standards
For the sake of compliance with IHE standard, the following is not met:
This section aims to provide a general description of the most important elements in those XML-schemas that together with WSDL-files, define the Web service operations described in section 3.
See description of contents of RetrieveDocumentSetRequestType in [ITI TF-2b].
See description of contents of RetrieveDocumentSetResponseType in [ITI TF-2b].
In the DDS Repository-solution, the interface between the actor-systems and the DDS Repository is versioned.
The interface specification constitutes the contract that defines how the systems involved must act.
The Interface specification consists of:
Versioning of resources takes place where it is not already defined by DGWS, the IHE standard or another Web service standard, by stating the release date in the form year/month as part of the URL that identifies the resource:
http://host/YYYY/MM/resource
WSDL file and XSD files are available in source code structure subfolder ddsservices\client-types\src\main\resources. These can also be downloaded from the following URL:
https://wsdl.nspop.dk/
---[HTTP request - http://localhost:9090/ddsrepository]--- Accept: text/xml, multipart/related, text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Content-type: multipart/related;start="<rootpart*5c8caa90-b074-4ed1-b609-2d4c13b37815@example.jaxws.sun.com>";type="application/xop+xml";boundary="uuid:5c8caa90-b074-4ed1-b609-2d4c13b37815";start-info="text/xml" Soapaction: "urn:ihe:iti:2007:RetrieveDocumentSet" --uuid:5c8caa90-b074-4ed1-b609-2d4c13b37815 Content-Id: <rootpart*5c8caa90-b074-4ed1-b609-2d4c13b37815@example.jaxws.sun.com> Content-Type: application/xop+xml;charset=utf-8;type="text/xml" Content-Transfer-Encoding: binary <?xml version="1.0" ?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Header> <ns10:Security xmlns:ns13="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns12="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns11="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd" xmlns:ns10="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns9="http://www.w3.org/2000/09/xmldsig#" xmlns:ns8="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns7="urn:oasis:names:tc:ebxml-regrep:xsd:cms:3.0" xmlns:ns6="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns5="urn:ihe:iti:xds-b:2007" xmlns:ns4="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"> <ns13:Timestamp> <ns13:Created>2016-12-17T14:43:10Z</ns13:Created> </ns13:Timestamp> <ns8:Assertion IssueInstant="2016-12-17T14:38:10Z" Version="2.0" id="IDCard"> <ns8:Issuer>TEST1-NSP-STS</ns8:Issuer> <ns8:Subject> <ns8:NameID Format="medcom:other">SubjectDN={SERIALNUMBER=CVR:30808460-UID:25351738 + CN=NETS DANID A/S - TU VOCES gyldig, O=NETS DANID A/S // CVR:30808460, C=DK},IssuerDN={CN=TRUST2408 Systemtest VIII CA, O=TRUST2408, C=DK},CertSerial={1276276200}</ns8:NameID> <ns8:SubjectConfirmation> <ns8:ConfirmationMethod>urn:oasis:names:tc:SAML:2.0:cm:holder-of-key</ns8:ConfirmationMethod> <ns8:SubjectConfirmationData> <ns9:KeyInfo> <ns9:KeyName>OCESSignature</ns9:KeyName> </ns9:KeyInfo> </ns8:SubjectConfirmationData> </ns8:SubjectConfirmation> </ns8:Subject> <ns8:Conditions NotBefore="2016-12-17T14:38:10Z" NotOnOrAfter="2016-12-18T14:38:10Z"/> <ns8:AttributeStatement id="IDCardData"> <ns8:Attribute Name="sosi:IDCardID"> <ns8:AttributeValue>U8Isxqp4txtGmVsfSzfgxw==</ns8:AttributeValue> </ns8:Attribute> <ns8:Attribute Name="sosi:IDCardVersion"> <ns8:AttributeValue>1.0.1</ns8:AttributeValue> </ns8:Attribute> <ns8:Attribute Name="sosi:IDCardType"> <ns8:AttributeValue>system</ns8:AttributeValue> </ns8:Attribute> <ns8:Attribute Name="sosi:AuthenticationLevel"> <ns8:AttributeValue>3</ns8:AttributeValue> </ns8:Attribute> <ns8:Attribute Name="sosi:OCESCertHash"> <ns8:AttributeValue>RngjckX+3IBZ0RNnWVXfuHDTa/Q=</ns8:AttributeValue> </ns8:Attribute> </ns8:AttributeStatement> <ns8:AttributeStatement id="SystemLog"> <ns8:Attribute Name="medcom:ITSystemName"> <ns8:AttributeValue>DDS - VOCES</ns8:AttributeValue> </ns8:Attribute> <ns8:Attribute Name="medcom:CareProviderID" NameFormat="medcom:cvrnumber"> <ns8:AttributeValue>30808460</ns8:AttributeValue> </ns8:Attribute> <ns8:Attribute Name="medcom:CareProviderName"> <ns8:AttributeValue>NETS DANID A/S - TU VOCES gyldig</ns8:AttributeValue> </ns8:Attribute> </ns8:AttributeStatement> <ns9:Signature id="OCESSignature"> <ns9:SignedInfo> <ns9:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ns9:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ns9:Reference URI="#IDCard"> <ns9:Transforms> <ns9:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ns9:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ns9:Transforms> <ns9:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ns9:DigestValue> <Include xmlns="http://www.w3.org/2004/08/xop/include" href="cid:253e1019-bd61-4c44-8d07-8dd62f246a15@example.jaxws.sun.com"/> </ns9:DigestValue> </ns9:Reference> </ns9:SignedInfo> <ns9:SignatureValue> <Include xmlns="http://www.w3.org/2004/08/xop/include" href="cid:b34faefa-3d17-4dd9-a2c8-54644ad4b58e@example.jaxws.sun.com"/> </ns9:SignatureValue> <ns9:KeyInfo> <ns9:X509Data> <ns9:X509Certificate> <Include xmlns="http://www.w3.org/2004/08/xop/include" href="cid:223986ce-7f5a-4bc5-9bbc-8fe0f7e8cb0b@example.jaxws.sun.com"/> </ns9:X509Certificate> </ns9:X509Data> </ns9:KeyInfo> </ns9:Signature> </ns8:Assertion> </ns10:Security> <ns12:Header xmlns:ns13="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns12="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns11="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd" xmlns:ns10="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns9="http://www.w3.org/2000/09/xmldsig#" xmlns:ns8="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns7="urn:oasis:names:tc:ebxml-regrep:xsd:cms:3.0" xmlns:ns6="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns5="urn:ihe:iti:xds-b:2007" xmlns:ns4="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"> <ns12:SecurityLevel>3</ns12:SecurityLevel> <ns12:Linking> <ns12:FlowID>urn:uuid:95427a32-cea8-4dd3-bfa8-7d6a7fc3e05c</ns12:FlowID> <ns12:MessageID>AAABWQ08kTMpuqZH/DCvw1NPU0k=</ns12:MessageID> </ns12:Linking> <ns12:RequireNonRepudiationReceipt>no</ns12:RequireNonRepudiationReceipt> </ns12:Header> <ns11:HsuidHeader xmlns:ns13="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns12="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns11="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd" xmlns:ns10="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns9="http://www.w3.org/2000/09/xmldsig#" xmlns:ns8="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns7="urn:oasis:names:tc:ebxml-regrep:xsd:cms:3.0" xmlns:ns6="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns5="urn:ihe:iti:xds-b:2007" xmlns:ns4="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"> <ns11:Assertion IssueInstant="2016-12-17T14:43:10.191Z" Version="2.0" id="HSUID"> <ns11:Issuer>DDSRegistry Test</ns11:Issuer> <ns11:AttributeStatement id="HSUIDdata"> <ns11:Attribute Name="nsi:UserType"> <ns11:AttributeValue>nsi:Citizen</ns11:AttributeValue> </ns11:Attribute> <ns11:Attribute Name="nsi:ActingUserCivilRegistrationNumber"> <ns11:AttributeValue>100000001</ns11:AttributeValue> </ns11:Attribute> <ns11:Attribute Name="nsi:SystemOwnerName"> <ns11:AttributeValue>System owner</ns11:AttributeValue> </ns11:Attribute> <ns11:Attribute Name="nsi:SystemName"> <ns11:AttributeValue>System name</ns11:AttributeValue> </ns11:Attribute> <ns11:Attribute Name="nsi:SystemVersion"> <ns11:AttributeValue>1.0</ns11:AttributeValue> </ns11:Attribute> <ns11:Attribute Name="nsi:OrgResponsibleName"> <ns11:AttributeValue>Org responsible for consuming service</ns11:AttributeValue> </ns11:Attribute> <ns11:Attribute Name="nsi:CitizenCivilRegistrationNumber"> <ns11:AttributeValue>100000001</ns11:AttributeValue> </ns11:Attribute> </ns11:AttributeStatement> </ns11:Assertion> </ns11:HsuidHeader> </S:Header> <S:Body> <ns5:RetrieveDocumentSetRequest xmlns:ns13="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns12="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns11="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd" xmlns:ns10="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns9="http://www.w3.org/2000/09/xmldsig#" xmlns:ns8="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns7="urn:oasis:names:tc:ebxml-regrep:xsd:cms:3.0" xmlns:ns6="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns5="urn:ihe:iti:xds-b:2007" xmlns:ns4="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"> <ns5:DocumentRequest> <ns5:RepositoryUniqueId>1.2.3.4.5.6.7.8.11</ns5:RepositoryUniqueId> <ns5:DocumentUniqueId>pdf</ns5:DocumentUniqueId> </ns5:DocumentRequest> <ns5:DocumentRequest> <ns5:RepositoryUniqueId>1.2.3.4.5.6.7.8.11</ns5:RepositoryUniqueId> <ns5:DocumentUniqueId>image</ns5:DocumentUniqueId> </ns5:DocumentRequest> <ns5:DocumentRequest> <ns5:RepositoryUniqueId>1.2.3.4.5.6.7.8.11</ns5:RepositoryUniqueId> <ns5:DocumentUniqueId>Doc6.1</ns5:DocumentUniqueId> </ns5:DocumentRequest> </ns5:RetrieveDocumentSetRequest> </S:Body> </S:Envelope> --uuid:5c8caa90-b074-4ed1-b609-2d4c13b37815 Content-Id: <253e1019-bd61-4c44-8d07-8dd62f246a15@example.jaxws.sun.com> Content-Type: application/octet-stream Content-Transfer-Encoding: binary I̮V࠴-Zۆy60 --uuid:5c8caa90-b074-4ed1-b609-2d4c13b37815 Content-Id: <b34faefa-3d17-4dd9-a2c8-54644ad4b58e@example.jaxws.sun.com> Content-Type: application/octet-stream Content-Transfer-Encoding: binary [Contents removed here] --uuid:5c8caa90-b074-4ed1-b609-2d4c13b37815---------------------- |
Some contents of response have been replaced with [Contents removed here] to improve readability.
---[HTTP response - http://localhost:9090/ddsrepository - 200]--- null: HTTP/1.1 200 OK Server: WildFly/8 Connection: keep-alive X-powered-by: Undertow/1 Date: Sat, 17 Dec 2016 14:43:10 GMT Transfer-encoding: chunked Content-type: multipart/related; type="application/xop+xml"; boundary="uuid:ed6c9e16-af67-4c91-aef3-7dc6a7bf00e9"; start="<root.message@cxf.apache.org>"; start-info="text/xml" --uuid:ed6c9e16-af67-4c91-aef3-7dc6a7bf00e9 Content-Type: application/xop+xml; charset=UTF-8; type="text/xml" Content-Transfer-Encoding: binary Content-ID: <root.message@cxf.apache.org> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> <ns7:Header xmlns:ns14="urn:dk.nsi.service" xmlns:ns13="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns12="urn:oasis:names:tc:ebxml-regrep:xsd:cms:3.0" xmlns:ns11="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns10="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns9="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:ns8="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd" xmlns:ns7="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns6="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns5="http://www.w3.org/2000/09/xmldsig#" xmlns:ns4="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns3="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns2="urn:ihe:iti:xds-b:2007" ns14:maxAge="24"> <ns7:Linking> <ns7:FlowID>urn:uuid:95427a32-cea8-4dd3-bfa8-7d6a7fc3e05c</ns7:FlowID> <ns7:MessageID>9c6353fa-0a89-4f54-ba66-47bba7d58e1d</ns7:MessageID> <ns7:InResponseToMessageID>AAABWQ08kTMpuqZH/DCvw1NPU0k=</ns7:InResponseToMessageID> </ns7:Linking> <ns7:FlowStatus>flow_finalized_succesfully</ns7:FlowStatus> </ns7:Header> </soap:Header> <soap:Body> <RetrieveDocumentSetResponse xmlns="urn:ihe:iti:xds-b:2007" xmlns:ns2="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns3="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns4="http://www.w3.org/2000/09/xmldsig#" xmlns:ns5="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns6="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns7="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd" xmlns:ns8="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:ns9="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns10="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns11="urn:oasis:names:tc:ebxml-regrep:xsd:cms:3.0" xmlns:ns12="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"> <ns9:RegistryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/> <DocumentResponse> <RepositoryUniqueId>1.2.3.4.5.6.7.8.11</RepositoryUniqueId> <DocumentUniqueId>pdf</DocumentUniqueId> <mimeType>application/pdf</mimeType> <Document> <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:b32c28c3-6cc7-4c53-bc94-c6bb10508c59-35037@urn%3Aihe%3Aiti%3Axds-b%3A2007"/> </Document> </DocumentResponse> <DocumentResponse> <RepositoryUniqueId>1.2.3.4.5.6.7.8.11</RepositoryUniqueId> <DocumentUniqueId>image</DocumentUniqueId> <mimeType>image/jpeg</mimeType> <Document> <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:b32c28c3-6cc7-4c53-bc94-c6bb10508c59-35038@urn%3Aihe%3Aiti%3Axds-b%3A2007"/> </Document> </DocumentResponse> <DocumentResponse> <RepositoryUniqueId>1.2.3.4.5.6.7.8.11</RepositoryUniqueId> <DocumentUniqueId>Doc6.1</DocumentUniqueId> <mimeType>text/xml</mimeType> <Document> <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:b32c28c3-6cc7-4c53-bc94-c6bb10508c59-35039@urn%3Aihe%3Aiti%3Axds-b%3A2007"/> </Document> </DocumentResponse> </RetrieveDocumentSetResponse> </soap:Body> </soap:Envelope> --uuid:ed6c9e16-af67-4c91-aef3-7dc6a7bf00e9 Content-Type: application/octet-stream Content-Transfer-Encoding: binary Content-ID: <b32c28c3-6cc7-4c53-bc94-c6bb10508c59-35037@urn:ihe:iti:xds-b:2007> [Contents removed here] --uuid:ed6c9e16-af67-4c91-aef3-7dc6a7bf00e9---------------------- |