aboutsummaryrefslogtreecommitdiff
path: root/src/main/resources
AgeCommit message (Collapse)AuthorFilesLines
2019-07-16DeliveryNotification: Change Mzs Schema, Convert From Msg to MzsChristof Rabensteiner1-4/+19
Mzs Schema Changes: - Formerly: The mzs:DeliveryNotificationType is a choice between Success And Error; Change: Wrap choice in a sequence. Reason: msg 2.0.0 adds fields that fit best in this sequence. Adding new fields to Success or Error duplicates code, whereas adding it to the base type (which is MessageType) also affects mzs:DeliveryRequestStatus. - Add msg:SenderDetails, ReceiverDetails, user, AdditionalFormat, NotificationsPerformed; Reason: It was added to zusemsg 2.0.0.
2019-07-16Implement ForwardResponseToService Sink And All Its ImplicationsChristof Rabensteiner3-0/+97
MZS Schema Change: - Add configuration for ForwardResponseToServiceSink (add parameters in mzs:DeliveryRequest/Config) - Add sink configuration in application.yaml, convert from Spring Environment to ConfigType, and merge ConfigTypes. - Validate sink configuration completeness. Contract added: - Add contract mzs2app.wsdl: This contract specifies how mzs:DeliveryRequestStatus' and mzs:DeliveryNotifications are forwarded to the sender application. - Implement "ForwardResponseToService" Sink. - Add and implement MsgResponse.sendToMzsClient() : This is a somewhat unfortunate solution because, intuitively, sending should be done by it's caller, the "ForwardResponseToService"-sink. However, this solution prevents differences between msg:DeliveryRequestStatus and msg:DeliveryNotification (and code that needs to handle differences, i.e. sending) from sprawling outside of the respective MsgResponse derivatives. We move the entire "send" process into MsgResponse to prevent a hard-to-maintain "if type == notification then do x else to y" construct in ForwardResponseToServiceSink. Otherwise, introducing the MsgResponse wrapper was pointless.
2019-07-15Save Response To File Sink: Add Path to Configuration + FixChristof Rabensteiner2-3/+12
- Fix in ConfigUtil: SaveResponseToFile boolean would override LogResponse configuration (Copy Paste Error).
2019-07-12Allow App To Choose Between MsgResponse SinksChristof Rabensteiner2-27/+41
- MZS Schema Change: Add "MsgResponseSinks" element to mzs:DeliveryRequest/Config that allows sender to configure how MsgResponses should be archived. - ConfigUtil: Interpret MsgResponseSink parameters from Spring Environment and merge with ConfigType. - MsgResponseBackend: Send responses to sinks according to MsgResponseSinks in Config - application.yaml: Add MsgResponseSinks parameter to configuration. - Uncouple Sink implementations from java.util.function.Function, because the sink interfaces are going to differ and there is no need to unite them under one interface. - Add and test LogResponseSink, which logs responses to it's logger. - MsgResponse: Add JAXB getter for response. Reason: Can be passed to marshaller.
2019-07-12Renamed and Simplified SignatureVerifierChristof Rabensteiner1-0/+1
2019-07-08Implement Zuse2App ServicesChristof Rabensteiner2-0/+85
- Add zuse2app.wsdl contract. - Add MsgResponse as an type-agnostic view for DeliveryRequestStatus and DeliveryNotification messages. Reason: Both DeliveryNotification and DeliveryRequestStatus messages have similar fields and need to be treated similarly (e.g.: receive from msg service, store to repository, verify signature, store to file...). In order to prevent duplicated code, the wrapper interface provides a type-agnostic view onto these messages for depending components to operate on. - Add MsgResponseHandler interface; decides how to process MsgResponse. Also implement this handler with a multi-threaded single-node implementation. - Add MsgResponseSink interface; decides how to archive MsgResponse. - Implement and test SafeResponseToFileSink. Change Identifier for MsgResponses: - Before, DeliveryRequestStatus and DeliveryNotifications had their own repositories. Now, both types are stored in the same repository (the MsgResponse repository) to streamline the handling of MsgResponses. We need to change the identification of MsgReponses, otherwise the identifiers (AppDeliveryID) clash. - MsgResponses are not identified by: <AppDeliveryId>+<typeSpecificSuffix> - Rewrite StoreSOAPInterceptor to accommodate fact that, both DeliveryRequestStatus and DeliveryNotification messages have different IDs upon storage / retrieval. Restructure packages and components as follows: - client: All components that are involved when consuming a web service. - process: "fabric" of MoaZS; contains business logic that orchestrates back-end tasks of MoaZS's operational services, e.g.: by processing a delivery request. - service: Implementation of MoaZS's front-end services. Refactoring: - MoaZSException: Remove unused fields. Before: Store mzsrequest, tnvzresult, msgrequest and msgresult as members. Now: Only keep the fields that are needed later, e.g for generating a msg:DeliveryRequestStatus element. Add copy constructor to Builder. - Put storage of byte[] into a dedicated "BinaryRepository". Reason: This was useful in a former design. Now it's not really needed anymore. - Put "create Endpoint" code into EndpointFactory. Reason: Eliminate duplicated code when configuring a service. Testing: - Activate Stacktraces in surefire.
2019-07-03Minor: Whitespace FixChristof Rabensteiner1-5/+5
2019-07-02Handle tnvz Query Edge Cases by Improving ValidationChristof Rabensteiner1-1/+0
TnvzHelper Fixes - Handle additional edge cases. - Mzs:Schema Change: Eliminate PreAdviceNote redundancy by removing it from mzs:DeliveryRequest/TnvzMetaData; PreadviceNote is already in the Receiver element. Update TnvzHelper accordingly. - Implement and integrate tnvz completeness check into DeliveryRequestAugmenter to ensure that, after augmentation, tnvz can be performed. Refactor mzs:DeliveryRequest Validation: - Before: Validating, merging and generatig ConfigType in ConfigUtil. - Change: Need to add validation of DeliveryRequest (Reason: For performing Tnvz Requests, the DeliveryRequest needs to be in a consistent state). - Problem: DeliveryRequest validation does not fit into ConfigUtil. - Solution: Put validation of DeliveryRequest and Config into new Component "MzsValidation".
2019-07-02Implement And Integrate tnvz:QueryPersonRequest.Christof Rabensteiner1-1/+16
- Merge TnvzClient and TnvzResultVerifier to TnvzHelper; TnvzHelper now builds the QueryPersonRequest, sends it to the tnvz port and evaluates the result. - Publish some interfaces in Mzs2MsgConverter because they are needed by TnvzHelper. - Generalize MsgClientFactory to ClientFactory such that it can be used to generate arbitrary SOAP clients (e.g. also for tnvz!). Schema Changes to accomodate Tnvz's QueryPersonRequest: - Add optional tnvz:AustrianAddressesOnly and optional TnvzMetaData to mzs:mzs:DeliveryRequest. Removed Unit Tests: - Remove subset of SameThreadDeliveryPipeline testcases (mimetype related) because its logic moved to TnvzHelper.
2019-06-27Honor & Test TrustAll and LaxHostNameVerificationChristof Rabensteiner5-0/+173
- Print a big scary warning message for everyone who enables "trustAll" - Test TrustAll and LaxHostNameVerification - Describe test case requirements and add key material needed to run these test cases.
2019-06-27Inject Configurable HTTP Policies to MsgClientChristof Rabensteiner2-2/+11
- Refactor: Get rid of MsgClient, because MsgClientFactory can do all the work. - Add Connection Timeout and Request Timeout (Policies of HTTP Client) to mzs:DeliveryRequest/Config and application.yaml. - Update readme: Add JDK 12 Requirement
2019-06-27Fixes; SSL Client Auth Works!Christof Rabensteiner4-30/+8
- Switch to java 12 for now. Reason: Bug [1] in JDK 11 (up to jdk-11+28) impairs SSLHandshake ("Unsupported Operation Exception"), but was fixed in Java 12. - Set HTTP policy to infinite. - Fix key/truststore path resolution - Fix NPE in ConfigUtil.merge - Rearrange application.yaml to include two config profiles (one with and one without SSL for the msg client). - Add key material for testcases (Note: expires: May 2 14:47:08 2020 GMT) - Update MsgClient Testcases [1] https://bugs.openjdk.java.net/browse/JDK-8214098
2019-06-26Protect MsgClient via SSL (ink Client Authentication)Christof Rabensteiner2-22/+41
- Add Component to create SSLContexts with own Key- and trust store. - Inject SSLContext into HTTP Client. - Add EAAF-Components Core Dependency, which is needed by SSLContextCreator (KeyStoreUtils). Schema Changes in mzs:DeliveryRequest/Config: - Got Rid of mzs:DeliveryRequest/Config/Server. In mzs 1.4.1, Server replaces the result of zkopf query person request. Since this zkopf interface does not exist anymore, Server was removed. - Add ClientType, which holds all parameters needed to connect to a service (Url, SSL params, a.o.). Configuration: - Add default parameters for SSL Clients in application.yaml. - Merge default parameters into incoming mzs:DeliveryRequests. MoaZSException Fixes: - Remove "Extends throwable" from Builder. - Add convenient shorthand init method (message, throwable). Refactor: - Put "determinePath" to FileUtils. - Put string related utility functions into StringUtils.
2019-06-19Finalize moa-sig-lib's Integration and Add TestcaseChristof Rabensteiner5-0/+2
- Interpret `ISignatureVerificationService` response properly (by following security layer spec [1] and moaspss handbook [2]). - Add config flag `moa.spss.is-manifest-check-active` - Change SignatureVerifier Interface: Remove @return boolean, just throw an exception when a validation error occurs. Reason: In case the signature cannot be validated, the application always needs the reason for the validation error, which requires the verifier to throw an exception. In turn, the only valid return value for `verify()` becomes `true`, which can be omitted at that point. - Add testcase for verifying a valid enveloped xml signature - Remove Certificates that are not needed. [1] https://www.buergerkarte.at/konzept/securitylayer/spezifikation/20140114/core/core.html [2] https://apps.egiz.gv.at/handbooks/moa-spss/handbook/handbook/usage/usage.html
2019-06-13Fix moa-sig-lib's Integration IssuesChristof Rabensteiner24-45/+287
Fixing "ASN.1 creation error: iaik.asn1.CodingException: Length: Too large ASN.1 object: 109" - Set fallback value ('jks') for system property 'javax.net.ssl.keyStoreType' and 'javax.net.ssl.trustStoreType'. If system property is not defined, MoaSigConfig falls back to value from spring environment. Reason: Without this property explicitly set to JKS, the inclusion of eaaf-components-moa-sig-lib breaks the HTTP client builder and the ASN.1 creation error arises. See [1] for explanation. - Why fall back: Allows a user to configure these parameters via command line, but gives meaningful defaults in case of absent command line properties. Furthermore, these parameters can be configured via application.yaml or .properties. Others: - Set fallback value for system property 'moa.spss.server.configuration'. If system property is not defined, fall back to value from spring environment. Reason: Allows a user to configure these parameters via command line while providing meaningful defaults in case of absent command line properties. - Add switch 'moa.spss.is-active' to enable / disable signature verification. - Change log levels of at.gv.* and iaik.* packages to INFO - Add default certstore (copied from EAAF Components). - Add mzs root certificate to cert- and truststore. - Update readme's installation requirements and guide. Refactor: - Extract public interface of SignatureVerification class. - Rename trustprofile folder. [1] Why eaaf-components-moa-sig-lib breaks HTTP client: - Including eaaf-components-moa-sig-lib includes IAIK's jca/jce and xsect, which in turn injects the iaik provider for cryptographic operations and its own key store (iaik.pkcs.pkcs12.PKCS12KeyStore). - The Apache HTTP client builder will ask for a java.base/javax.net.ssl.SSLSocketFactory because it creates an SSL context, even if the connection runs without SSL. - Somewhere down the stack, this will trigger the TrustStoreManager to hand over the systems default trust store (a JKS file) to IAIK's PKCS12KeyStore. This happens if the type properties of the trust stores are not set. - Oracle relaxed a precondition of this trust store (somewhere in between Java 8 and 11) in the TrustStoreManager: Formerly, the trust store was a JKS object. Now, the trust store can be both a JKS and a PKCS12 object. The TrustStoreManager expects the key store to handle both types, and Oracle's keystore does. However, IAIK's key store cannot handle a JKS object, but since eaaf-components-moa-sig-lib was included, the IAIK key store comes first. - PKCS12KeyStore expects a PKCS12 file but receives a JKS file -> Parser Error.
2019-05-29Integrate MoaSig Verification into SignatureVerifierChristof Rabensteiner3-0/+113
- Verify signature via ISignatureVerificationService. - Override System Property moa.spss.server.configuration via spring's environment (Reason: can configure path to moa SPSS config file via application.yaml & moa SPSS needs this parameter to find the config file) - Setup test configuration directory for moaspss in src/main/resources/moa-spss - Readme: Explain how to install moaspss' dependencies into local repository.
2019-05-28Add Moa Sig Dependency & Configure Logging & Init ReadmeChristof Rabensteiner2-5/+21
- Reduce logger output of all contexts to ERROR and WARN Statements; Moazs can log to INFO. Reason: Including moa-sig causes lots of DEBUG / TRACE logging . - Add Repository that points to file://${basedir}/repository. - Add guide how to compile project (I dont check moa-sig depenendcies into repository but explain how to retrieve dependencies manually in readme.md.)
2019-05-23MZS Schema Changes + Changes in InterfaceChristof Rabensteiner1-28/+19
- MZS cant reply with a msg:DeliveryRequestStatusType to a mzs:DeliveryRequest. Reason: unmarshalling a msg:DeliveryRequestStatusType with JAXB (after receiving the msg reply) breaks the signature in msg:DeliveryRequestStatusType. Why? Because JAXB marshalling tinkers with the namespaces and, as for the current state of knowledge, we cannot configure the JAXB marshaller to reconstruct a XML Document byte-by-byte such that a signature that went through this process can be verified successfully (see [1]). - For this reason, we revert back to mzs:DeliveryResponse and add new fields / remove obsolete fields / capture all changes between zusemsg 1.5.3 and zusemsg 2.0.0. - The easier solution would be to wrap and transmit signed data + signature in a binary (base64) container, such that apache cxf and other web service frameworks won't unmarshall them. This doesnt work because zusemsg 2.0.0 is final. app2mzs.xsd Changes in Detail : - Add DeliverySystem, ZSDeliveryID and GZ to MessageType (MessageType is the base type of DeliveryResponse.Success, -PartialSuccess, and -Error); Reason: It was added to zusemsg 2.0.0. - Add SignedDeliveryRequestStatus to MessageType. Reason: If msg returns signed reply, this element contains the reply as byte[] such that the signature does not break. - Add optional PreadvicenoteSend to ErrorType (because it was added in zusemsg 2.0.0) - Remove MZSDeliveryID from every instance because this ID does not exist anymore (moa zs does not maintain requests in a database). - Remove DocumentReference from ErrorType as it was removed from zusemsg 2.0.0. - Remove DeliveryConfirmation as node in DeliveryNotificiationType because it does not exist anymore in zusemsg 2.0.0; DeliveryConfirmation is also obsolete because all msg' replies are signed and need to be transferred to the sender application as a byte[], which is done by SignedDeliveryRequestStatus node in MessageType. - Remove DeliveryStatement as node in DeliveryNotificiationType because it does not exist anymore in zusemsg 2.0.0. Other Changes - Adapt codebase: MzsService returns mzs:DeliveryResponse. - Implement conversion from msg:DeliveryRequestStatus to mzs:DeliveryResponse. - Add store / retrieve interface to DeliveryRepository that stores signed delivery request statuses as byte[]. Temporary Changes - Disable integration tests which have external dependencies. [1] https://download.oracle.com/javaee-archive/jaxb.java.net/users/2007/03/6674.html Signed-off-by: Christof Rabensteiner <christof.rabensteiner@iaik.tugraz.at>
2019-05-21WIP: SSL Client AuthChristof Rabensteiner1-3/+38
- Refactor MsgClient: Not a Singleton anymore. Use MsgClientFactory to make a client. Make request and config private fields. - Add configuration parameters to application.yaml. - Init SSL client auth testcase, but dont include in testsuite because it aint working yet.
2019-05-20Add Testcase for MsgClientChristof Rabensteiner2-2/+1
2019-05-15Handle Config Related Edge Cases in Augmenter & ProfileGeneratorChristof Rabensteiner1-1/+6
ConfigProfileGenerator: - Cancel startup if default Config profile is incomplete. - Add property flag 'verify-completeness-of-default-delivery-request-configuration', which allows admin to disable completeness check. In that case, just log a warning if the default profile is incomplete. Augmenter: - Ensure that after merging the config is complete (or throw an exception otherwise). - Refactor: Move ConfigProfileValidator from ConfigProfileGenerator to dedicated "ConfigProfileValidator" class; Reason: Augmenter needs to check completness of at-runtime-compiled configuration. - Refactor: Rewrote code for better readability. Others - NPE Fix in ConfigProfileMerger: If FallbackConfigProfile/Server is empty, use PrimaryProfile/Server.
2019-05-15Integrate Config Profiles + RefactoringChristof Rabensteiner1-1/+1
Config Profile Integration: - Merge generated Configs from ConfigProfileGenerator with the default Config; Reason: Merging profile Configs with default Config asap ensures that profile Configs are "as complete as possible" while allowing profile Configs to "on-demand"-override values from the default Config. - Adapt Augmenter to work with Config profiles: Select a Config on the basis of on msg:DeliveryRequest/Config/ProfileId, fall back to 'default' Config. - Schema change: Make ProfileID optional. Refactoring: - Move Config-merging code from Augmenter into dedicated 'ConfigProfileMerger' class. - ConfigProfileGenerator: Clarify stream pipeline and comply with coding standard w.r.t. constant members. - Add Augmenter test cases for profile selection.
2019-05-15WIP: Generate Map of Config Profiles from Spring EnvironmentChristof Rabensteiner3-4/+30
Augmenter - Replace default Config Profile with map of Config Profiles. Now, Augmenter can choose a config profile at runtime and augment it. - Move Augmenter to sub package. WIP - Implement ConfigProfileGenerator, which retrieves Config profiles from Spring Environment and returns an easy-to-use map with profiles that is keyed with profile id's. - Replace application.properties with application.yaml. - Remove Augmenter test cases: They need to be adapted.
2019-05-14Implement Per-Field-Overriding of Configuration in AugmenterChristof Rabensteiner1-9/+10
- Rewrite DeliveryRequestAugmenter to allow per-field-overriding of configuration parameters and add test suite. - Mzs schema change: Move DeliveryRequest/Server into DeliveryRequest/Config; Reason: DeliveryRequest/Config contains all parameters exclusively needed by moazs to execute the delivery request. The msg's server url belongs to this set of parameters. - WIP: Add prototype implementation of MsgClient and move MsgClient to dedicated package. - Refactor: move TnvzClient to dedicated package.
2019-05-08WIP delivery request validationChristof Rabensteiner1-1/+0
2019-05-08Implement Pipeline Flow and mzs2msg ConversionChristof Rabensteiner2-10/+5
- Implement and test conversion from mzs:DeliveryRequest to msg:DeliveryRequest with the "convert-pojos-by-hand"-strategy. Reason: The chosen strategy benefits from JAXB's strong typing, which is useful in this scenario: Differences between msg and mzs are nuanced and easy to overlook. The chosen strategy is, unfortunately, verbose and could become expensive to maintain. - Update SameThreadDeliveryPipeline: Integrate tnvz query, conversion, and msg query. - Add MsgClient stub. tnvz: - Change TnvzClient stub interface. - Implement mimetype mismatch check from tnvz Response. - Put p:Identification from tnvz response into msg:DeliveryRequest. MZS Schema changes: - Replace DeliveryRequest/Sender/Person with CorporateBody (because thats the only sender that is allowed by zusemsg) and add a SenderProfile choice. - Add ID Attribute to DeliveryRequest/Sender because msg/DeliveryRequest/Sender/AbstractSenderPersonType also has an id attribute. - Remove PersonDataType because it's dead code.
2019-05-06Add zusetnvz SchemaChristof Rabensteiner4-0/+620
2019-04-30Add Optional mzs:DeliveryRequest/Config & Validate / Augment ItChristof Rabensteiner1-0/+7
Add Optional "Config" to MZS Schema: - Add mzs:DeliveryRequest/Config Element with a "PerformQueryPersonRequest" node - The config element contains parameters that are interpreted by moa-zs and not forwarded to the ZD - The boolean PerformQueryPersonRequest tells moa-zs if moa-zs should perform a QueryPersonRequest towards the TNVZ. - If config is missing, moa-zs augments the delivery request with parameters from the app's configuartion or the default configuartion Other Changes: - Validate and augment incoming requests with the DeliveryPreprocessor. - Add stub for TlnvzClient. - Remove some leftover ObjectFactory imports (because of the builder they are not needed anymore) Fixes - Fixed incorrect API usage of Messageformat.format: format string needs an index. pom.xml - Add Hamcrest Dependency (for writing more expressive tests) - Add copy constructor to JAXB Builder Testing - Test validation of incoming request - Refactor testcases to improve readability
2019-04-18Change App2mzs Interface and Init Delivery PipelineChristof Rabensteiner1-13/+1
- Change app2mzs interface: output message from app2mzs:DeliveryRequest was app2mzs:DeliveryResponse, now its msg:DeliveryRequestStatus. Reason: ZD returns msg:DeliveryRequestStatus which is signed. Moazs does not convert msg:DeliveryRequestStatus into app2mzs:DeliveryResponse because the conversion woudl break the signature. - App2MzsService: Make beans final and inject them with constructor; Refactor DeliveryRequestHandler into App2MZSService. - DeliveryPipeline: Add Interface and a "SameThreadImplementation" that executes the pipeline in the same threat and can be used in single mode. - DeliveryRepository: Augment interface for storing and retrieving request status objects; Add in-memory-implementation for status objects. - Utils: Add helper function for coalescing multiple values
2019-04-17Add Redis and InMemory Implementation of DeliveryRequestRepositoryChristof Rabensteiner1-0/+2
- Deployer can choose which implementation to use (by activating - corresponding profile) - Add guava dependency - Extract DeliveryRequestRepository to Interface - Implement InMemory Repository using guava's cache
2019-04-16Store incoming delivery request on redis serverChristof Rabensteiner1-0/+2
- Connect to Redis server and implement RedisRepository - Add redis dependencies (spring-boot-starter, jedis, apache commons io). Latter dependencies are apparently needed and not included in the sprint-boot-starter; See https://github.com/spring-projects/spring-boot/issues/5718 and https://www.concretepage.com/questions/599 - Connect DeliveryRequestHandler to RedisRepository - Rewrote Marshalling: replace JaxbContext with spring-oxm JaxbMarshaller - Catch and log all exceptions in App2MZSService; Former: certain exceptions would go unnoticed, e.g. ConnectionRefused
2019-04-09Propagate changes of zusemsg2.0.c into mzsChristof Rabensteiner1-16/+2
- Add Target to CorporateBodyType - Remove Authority - make DateOfBirth optional
2019-04-09Update zusemsg Spec to 2.0.cChristof Rabensteiner3-35/+13
2019-04-08Fix mzs:DReq/PayloadChristof Rabensteiner1-2/+2
- make one Payload Element mandatory - fix refernce to msg:DocumentClass
2019-04-08Update mzs:DReq/Payload SchemaChristof Rabensteiner1-3/+3
2019-04-08Schema FixesChristof Rabensteiner1-2/+2
2019-04-08Update mzs:DeliveryRequest/Receiver Schema to fit zusemsg needsChristof Rabensteiner1-1/+15
- add choice between Identification and Person/Address - add AdditionalCriteria and PreAdvice not
2019-04-08Update mzs:DeliveryRequest SchemaChristof Rabensteiner2-163/+12
- Remove MZSDreq/Sender/ConfirmationAddress (because its already Available in Sender/{WebserviceURL,EmailAddress}) - Simplify MZSDReq/Receiver (no actual schema change, just refactoring) - Remove XML Payload (because this delivery method does not exist in zusemsg) - Simplify Payload Schema and adapt it to zusemsg:Attachment - Remove DayOfBirthType (because dead code) - Metadata: replace mzs definition of metadata with reference to msg:Metadata. Reason: Both interfaces work the exact same way so there is no reason in not reusing the interface. Using the same interface definitions does not affect the integration effort for app developers, because the msg:metadata changed quite drastically and app developers will need to integrate these changes anyways. The changes in zusemsg:Metadata are so invasive that MOAZS cannot prevent them from propagating into the app2mzs interfaces. A benefit from reusing the msg:MetaData interface is that there will be less types, less duplicate code, less repetition, and therefore cleaner and easier to maintain.
2019-04-08Add app2zuse WSDL and FriendsChristof Rabensteiner3-0/+571
2019-04-05Schema changesChristof Rabensteiner1-1/+6
- Add MessegerService, make InternetAddressType url mandatory
2019-04-05Add PostalAddress TypeChristof Rabensteiner1-0/+10
2019-04-05Remove Country Code RestrictionChristof Rabensteiner1-0/+5
2019-04-05Remove Country Code RestrictionChristof Rabensteiner1-6/+1
2019-04-05Remove AnyAttribute from AbstractAddressTypeChristof Rabensteiner1-1/+0
2019-04-05Remove AnyAttribute from AbstractPersonTypeChristof Rabensteiner1-1/+0
2019-04-05Whitespace FixChristof Rabensteiner1-4/+4
2019-04-05PersonName: Add AffixChristof Rabensteiner1-0/+33
2019-04-05mzs:Sender: Remove ProfileIDChristof Rabensteiner1-28/+23
2019-04-04Update zusemsg schemes to v2.0.bChristof Rabensteiner2-592/+508
2019-04-03Make Corporate/FullPerson MandatoryChristof Rabensteiner1-1/+1
- Reason: mandatory in zusemsg2.0.0