schemas.peppol-smp-types-v1-ext.xsd Maven / Gradle / Ivy
The SignedServiceMetadata structure is a ServiceMetadata structure
that has been signed by the ServiceMetadataPublisher, according to governance policies.
The ServiceMetadata element covered by the signature.
Represents an enveloped XML signature over the SignedServiceMetadata element.
This data structure represents Metadata about a specific electronic service.
The role of the ServiceMetadata structure is to associate a participant identifier
with the ability to receive a specific document type over a specific transport. It
also describes which business processes a document can participate in, and various
operational data such as service activation and expiration times.
The ServiceMetadata resource contains all the metadata about a service that a sender
Access Point needs to know in order to send a message to that service.
Contains service information for an actual service registration, rather than a redirect to another SMP
For recipients that want to associate more than one SMP with their participant identifier,
they may redirect senders to an alternative SMP for specific document types. To achieve
this, the ServiceMetadata element defines the optional element ‘Redirect’. This element
holds the URL of the alternative SMP, as well as the Subject Unique Identifier of the
destination SMPs certificate used to sign its resources.
In the case where a client encounters such a redirection element, the client MUST follow
the first redirect reference to the alternative SMP. If the SignedServiceMetadata resource
at the alternative SMP also contains a redirection element, the client SHOULD NOT follow
that redirect. It is the responsibility of the client to enforce this constraint.
The participant identifier. Comprises the identifier, and an identifier scheme. This identifier MUST have the same value of the {id} part of the URI of the enclosing ServiceMetadata resource.
Represents the type of document that the recipient is able to handle.
Represents the processes that a specific document type can participate in, and endpoint address and binding information. Each process element describes a specific business process that accepts this type of document as input and holds a list of endpoint addresses (in the case that the service supports multiple transports) of services that implement the business process, plus information about the transport used for each endpoint.
The extension element may contain any XML element. Clients MAY ignore this element.
List of processes
The identifier of the process.
List of one or more endpoints that support this process.
The extension element may contain any XML element. Clients MAY ignore this element.
Contains a list of all endpoint
Endpoint represents the technical endpoint and address type of the recipient, as an URL.
The address of an endpoint, as an WS-Addressing Endpoint Reference
Set to "true" if the recipient requires business-level signatures for the message, meaning a signature applied to the business message before the message is put on the transport. This is independent of the transport-level signatures that a specific transport profile, such as the START profile, might mandate. This flag does not indicate which type of business-level signature might be required. Setting or consuming business-level signatures would typically be the responsibility of the final senders and receivers of messages, rather than a set of APs.
Indicates the minimum authentication level that recipient requires. The specific semantics of this field is defined in a specific instance of the BUSDOX infrastructure. It could for example reflect the value of the "urn:eu:busdox:attribute:assurance-level" SAML attribute defined in the START specification.
Activation date of the service. Senders should ignore services that are not yet activated.
Expiration date of the service. Senders should ignore services that are expired.
Holds the complete signing certificate of the recipient AP, as a PEM base 64 encoded X509 DER formatted value.
A human readable description of the service
Represents a link to human readable contact information. This might also be an email address.
A URL to human readable documentation of the service format. This could for example be a web site containing links to XML Schemas, WSDLs, Schematrons and other relevant resources.
The extension element may contain any XML element. Clients MAY ignore this element.
Indicates the type of BUSDOX transport that is being used between access points, e.g. the BUSDOX START profile. This specification defines the following identifier URI which denotes the BUSDOX START transport: "busdox-transport-start"
The ServiceGroup structure represents a set of services
associated with a specific participant identifier that is handled by a
specific Service Metadata Publisher. The ServiceGroup structure holds a
list of references to SignedServiceMetadata resources in the ServiceList
structure.
Represents the business level endpoint key and key type, e.g. a DUNS or GLN number that is associated with a group of services.
The ServiceMetadataReferenceCollection structure holds a list of references to SignedServiceMetadata structures. From this list, a sender can follow the references to get each SignedServiceMetadata structure.
The extension element may contain any XML element. Clients MAY ignore this element.
Contains the URL to a specific SignedServiceMetadata instance. Note
that references MUST refer to SignedServiceMetadata records that are signed by the
certificate of the SMP. It must not point to SignedServiceMetadata resources published
by external SMPs.
Contains the URL to a specific SignedServiceMetadata instance.
Holds the Subject Unique Identifier of the certificate of the destination SMP. A client SHOULD validate that the Subject Unique Identifier of the certificate used to sign the resource at the destination SMP matches the Subject Unique Identifier published in the redirecting SMP.
The extension element may contain any XML element. Clients MAY ignore this element.
The destination URL of the redirect.
Child elements of the [smp:Extension] element are known as "custom
extension elements". Extension points may be used for optional extensions
of service metadata. This implies:
* Extension elements added to a specific Service Metadata resource MUST be ignorable
by any client of the transport infrastructure. 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.
* A client MAY ignore any extension element added to specific service metadata
resource instances.
© 2015 - 2025 Weber Informatics LLC | Privacy Policy