diff --git a/5.0 Draft/IDD/IDDs Authorization System/eu.arrowhead.authorization-http-json.yml b/5.0 Draft/IDD/IDDs Authorization System/eu.arrowhead.authorization-http-json.yml index 58d9d05..9465fb2 100644 --- a/5.0 Draft/IDD/IDDs Authorization System/eu.arrowhead.authorization-http-json.yml +++ b/5.0 Draft/IDD/IDDs Authorization System/eu.arrowhead.authorization-http-json.yml @@ -58,14 +58,6 @@ info: payloads up to 4096 bytes in size. If payload compression is supported, then this limit applies after decompression. version: 5.0.0-rc.1 - - # Additional information present in the IDD template - x-transfer-protocol: [HTTP, HTTPS] - x-encryption-method: to-add - x-encoding: JSON - x-compression: to-add - x-semantics: to-add - x-Ontology: to-add paths: diff --git a/5.0 Draft/IDD/IDDs Authorization System/eu.arrowhead.authorization-management-http-json.yml b/5.0 Draft/IDD/IDDs Authorization System/eu.arrowhead.authorization-management-http-json.yml index 66cda5f..6bb3576 100644 --- a/5.0 Draft/IDD/IDDs Authorization System/eu.arrowhead.authorization-management-http-json.yml +++ b/5.0 Draft/IDD/IDDs Authorization System/eu.arrowhead.authorization-management-http-json.yml @@ -36,13 +36,6 @@ info: version: 1.0.0 - # Additional information present in the IDD template - x-transfer-protocol: [HTTP, HTTPS] - x-encryption-method: to-add - x-encoding: JSON - x-compression: to-add - x-semantics: to-add - x-Ontology: to-add paths: /ping: diff --git a/5.0 Draft/IDD/IDDs Orchestration System/eu.arrowhead.orchestration-pull-http-json.yml b/5.0 Draft/IDD/IDDs Orchestration System/eu.arrowhead.orchestration-pull-http-json.yml index 858f8be..66ea46b 100644 --- a/5.0 Draft/IDD/IDDs Orchestration System/eu.arrowhead.orchestration-pull-http-json.yml +++ b/5.0 Draft/IDD/IDDs Orchestration System/eu.arrowhead.orchestration-pull-http-json.yml @@ -3,12 +3,11 @@ openapi: 3.0.3 info: title: Service Orchestration-pull service API description description: | - An API for using the Service Orchestration-pull service of the Orchestration core system. This service - uses the orchestration store policies to recommend service providers to the requesting consumer to fulfil - its task. + An API for using the Service Orchestration-pull service of the Orchestration core system. This service uses the orchestration store policies + to recommend service providers to the requesting consumer to fulfil its task. - The consumer system request for orchestration either by specifying the service definition that the consumer requires or - by using stored SoS configurations or Orchestration rules if no service information is defined. + The consumer system request for orchestration either by specifying the service definition that the consumer requires or by using stored SoS + configurations or Orchestration rules if no service information is defined. _SoS configurations_ represents the connections needed in a SoS for it to perform its designed task. This means, describing what services must each of the systems consume to perform their individual tasks. A SoS configuration can be seen as a series of _Orchestration rules_. @@ -17,18 +16,10 @@ info: In the context of this document, we reffer to the Orchestration consumer as _requesting-system_ where _system-id_ is the unique identifier that represents that system. The _requested-service_ represents the service information that the _requesting-system_ requires orchestration. In case the _requested_service_ is specified, the requires service definition must be included in the form, - in addition, at least one interface must be specified. The orchestration system will attempt to match the _requested-service_ information - with services present on the orchestration rules or SoS configurations. - version: 5.0.0-rc.1 - + The orchestration system will attempt to match the _requested-service_ information with services present on the orchestration rules or SoS + configurations. -# Additional information present in the IDD template -x-transfer-protocol: [HTTP, HTTPS] -x-encryption-method: to-add -x-encoding: JSON -x-compression: to-add -x-semantics: to-add -x-Ontology: to-add + version: 5.0.0-rc.1 paths: /orchestration/echo: @@ -47,7 +38,7 @@ paths: on a existing SoS configuration or Orchestration rules. Information of the requesting system is mandatory. Requested service is optional. If a requested service object is specified, - the service definition and at least one interface must be specified. + the service definition must be specified. requestBody: required: true content: @@ -91,63 +82,13 @@ paths: components: schemas: - Address: - description: | - Identifies a _transport_ and a _location_. - - The _transport_ identifies the base protocol that facilitates addressing a specific service - instance. Examples of transports that can be supported are `tcp4`, `tcp6`, `udp4`, `udp6` - and `unix`. A protocol only counts as a transport if it both (A) provides a way of - addressing and, by extension, sending messages to service providers and consumers, as well - as (B) does not build upon another protocol also providing this capability. I other words, - TLS and DTLS are _not_ transports, because they build upon the TCP and UDP protocols, which - satisfy condition A. - - What the _location_ part consists of depends on what transport is identified. If the - transport is `tcp4` or `udp4`, the location is an IPv4 address expressed as four decimal - numbers separated by dots, a colon and a port number, such as in `192.168.3.22:64075`. If - the transport is `tcp6` or `udp6`, the location is an IPv6 address, rendered as described in - [RFC 5952](https://www.rfc-editor.org/rfc/rfc5952), within square brackets, followed by a - colon and a port number. If the transport is `unix`, the location is an absolute filesystem - path to a Unix socket file. - type: string - pattern: ^(?[^:]+):\w*(?.*)$ - example: tcp4:192.168.0.7:45326 Auth-tokens: description: | - An (k,v) object containing authorization tokens for each interface contained in the response + An (k,v) object containing authorization tokens required to consume orchestration services type: object example: {"interfaceName1":"token1"} - Interface: - description: An object describing interfaces used by services. This object contains information on the used - protocol and the security requirements. Depending on the protocol, additional properties could be appropriate, - such as 'version', 'contentTypes', 'ipv4Address', 'port', 'x509PublicKey', 'basePath' or 'topic'. The same - applying to security. - type: object - properties: - protocol: - type: object - properties: - name: - type: string - description: "Transport protocol, such as 'https', 'coaps+tcp', 'json-rpc', or 'mqtt'" - additionalProperties: true - required: - - name - security: - type: array - items: - type: object - properties: - name: - type: string - description: "Security method name, such as 'tokenAuthentication'" - additionalProperties: true - required: - - name - Metadata: description: | Additional details of relevance when consuming a service. What metadata is made available @@ -156,56 +97,7 @@ components: type: object example: {"basePath":"v2"} - PreferredProvider: - type: object - description: information of a preferred provider to consume services from. - properties: - provider-cloud: - $ref: '#/components/schemas/ProviderCloud' - provider: - $ref: '#/components/schemas/ProviderSystem' - - ProviderSystem: - type: object - description: information describing a provider system within a local cloud. - properties: - system-name: - type: string - address: - $ref: '#/components/schemas/Address' - - ProviderCloud: - type: object - description: an object describing the cloud in which a provider is located - properties: - operator: - type: string - description: Name of the operator company - name: - type: string - description: name of the cloud - - RequesterSystem: - type: object - description: Information of the system requesting orchestration information. - properties: - system-name: - type: string - description: Short human readable system name. - systemID: - type: string - description: unique identifier of requester system - address: - $ref: '#/components/schemas/Address' - auth-info: - type: string - description: Authentication info, i.e, CERTIFICATE, TOKEN, etc. - interface: - type: array - items: - $ref: '#/components/schemas/Interface' - - RequestedService: #TODO: How much of this information should be asked? + RequestedService: type: object description: | Optional information of the required service. This object contains the service requirements of the requester @@ -214,11 +106,9 @@ components: service-definition: type: string description: Service definition string identifier - interfaces: - type: array - description: Interface requirement - items: - $ref: '#/components/schemas/Interface' + service-type: + type: string + description: Service type string identifier version: $ref: '#/components/schemas/VersionReq' required: @@ -232,13 +122,6 @@ components: description: service instance unique identifier, the consumer getting the response use this to query the service registry to get full service information and connection address. - SecurityType: - type: string - enum: - - TOKEN - - NON-SECURE - - CERTIFICATE - ServiceRequestForm: type: object properties: @@ -250,10 +133,6 @@ components: description: Requesting system unique identifier requested-service: $ref: '#/components/schemas/RequestedService' - preferred-providers: - type: array - items: - $ref: '#/components/schemas/PreferredProvider' OrchestrationResponse: type: object diff --git a/5.0 Draft/IDD/IDDs Orchestration System/eu.arrowhead.orchestration-push.yml b/5.0 Draft/IDD/IDDs Orchestration System/eu.arrowhead.orchestration-push.yml index a1e6ab1..047c298 100644 --- a/5.0 Draft/IDD/IDDs Orchestration System/eu.arrowhead.orchestration-push.yml +++ b/5.0 Draft/IDD/IDDs Orchestration System/eu.arrowhead.orchestration-push.yml @@ -15,14 +15,6 @@ info: version: 5.0.0-rc.1 -# Additional information present in the IDD template -x-transfer-protocol: [to-add] -x-encryption-method: to-add -x-encoding: JSON -x-compression: to-add -x-semantics: to-add -x-Ontology: to-add - channels: pushConfiguration: address: 'orchestration/push' @@ -78,9 +70,10 @@ components: items: $ref: '#/components/schemas/Rule' target: - type: object + type: array description: Target of the orchestration configuration - #TODO: define how the target should look like, is it just one target? is it an array of targets? Are the targets within the rules? + items: + $ref: '#/components/schemas/System' Metadata: description: | diff --git a/5.0 Draft/IDD/IDDs Orchestration System/eu.arrowhead.orchestration-store-management-http-json.yml b/5.0 Draft/IDD/IDDs Orchestration System/eu.arrowhead.orchestration-store-management-http-json.yml index 2cb5135..2ef641f 100644 --- a/5.0 Draft/IDD/IDDs Orchestration System/eu.arrowhead.orchestration-store-management-http-json.yml +++ b/5.0 Draft/IDD/IDDs Orchestration System/eu.arrowhead.orchestration-store-management-http-json.yml @@ -19,13 +19,6 @@ info: is valid in the local cloud. version: 5.0.0-rc.1 -# Additional information present in the IDD template -x-transfer-protocol: [HTTP, HTTPS] -x-encryption-method: to-add -x-encoding: JSON -x-compression: to-add -x-semantics: to-add -x-Ontology: to-add paths: /orchestration/rules: @@ -234,9 +227,14 @@ components: serviceID: type: string description: identifier of service - serviceInstance: + serviceDefinition: type: string description: name of the service instance + serviceType: + type: string + description: name of the service type + version: + $ref: '#/components/schemas/Version' System: type: object @@ -253,3 +251,10 @@ components: pattern: ^(?:(\d+)d)?(?:(\d+)h)?(?:(\d+)m)?(?:(\d+)s)?$ example: 2d12h + Version: + description: | + A MAJOR, MINOR and a PATCH number, separated by dots. If both or the latter of the MINOR and + PATCH numbers are omitted, the ones omitted are assumed to be zero. + type: string + pattern: ^\d+(?:\.\d+(?:\.\d+)?)?$ + example: 1.4 \ No newline at end of file diff --git a/5.0 Draft/IDD/IDDs Service Registry/eu.arrowhead.service-discovery-http-json.yml b/5.0 Draft/IDD/IDDs Service Registry/eu.arrowhead.service-discovery-http-json.yml index b8702b9..e28d8d5 100644 --- a/5.0 Draft/IDD/IDDs Service Registry/eu.arrowhead.service-discovery-http-json.yml +++ b/5.0 Draft/IDD/IDDs Service Registry/eu.arrowhead.service-discovery-http-json.yml @@ -49,7 +49,6 @@ info: Every service instance registered via this service interface _must_ be associated with a unique identifier. In contexts where authentication is not used, providers _must_ chose their own identifiers. Those identifiers _should_ remain consistent between restarts of those providers. - In contexts where authentication is used, the identifier _must_ be derived as follows: TODO. ## Size Limits @@ -59,13 +58,6 @@ info: limit the sizes of individual parts within each request. It _must_, however, receive request URI:s up to 2816 bytes in size, as well as request payloads up to 4096 bytes in size. version: 5.0.0-rc.1 - # Additional information present in the IDD template - x-transfer-protocol: [HTTP, HTTPS] - x-encryption-method: to-add - x-encoding: JSON - x-compression: to-add - x-semantics: to-add - x-Ontology: to-add paths: diff --git a/5.0 Draft/IDD/IDDs Service Registry/eu.arrowhead.service-registry-administration-http-json.yml b/5.0 Draft/IDD/IDDs Service Registry/eu.arrowhead.service-registry-administration-http-json.yml index 091960c..b7bfb69 100644 --- a/5.0 Draft/IDD/IDDs Service Registry/eu.arrowhead.service-registry-administration-http-json.yml +++ b/5.0 Draft/IDD/IDDs Service Registry/eu.arrowhead.service-registry-administration-http-json.yml @@ -8,15 +8,48 @@ info: registry catalog. To register a service, the service provider, a system administrator, or a supporting system must fill a _ServiceEntry_ object with the details of the service and the service provider. Additional inforation can be especified in the _metadata_ parameter. - version: 1.0.0 - # Additional information present in the IDD template - x-transfer-protocol: [HTTP, HTTPS] - x-encryption-method: to-add - x-encoding: JSON - x-compression: to-add - x-semantics: to-add - x-Ontology: to-add + ## Compression and Language + + An implementation of this service interface _may_ be designed to support compression and/or + human-readable error texts in different languages than English, as described in + [RFC 9110, Section 12](https://www.rfc-editor.org/rfc/rfc9110#name-content-negotiation). Not + using compression _must_ be supported and be the default. Also, the default language for error + messages _must_ be American English (`en-US`). + + ## Managing Record Life-Cycles + + In a typical use case, this service interface is meant to hold records for all service providers + currently part of its context. When a service provider joins or leaves a context, it is expected + to register and deregister its services, respectively. However, service providers can fail or be + detached from the context before they get a chance to deregister their services. This can make + it relevant to monitor service providers and temporarily suppress or permanently prune records + associated with unhealthy or inaccessible providers. Implementations of this service interface + are free to suppress and/or prune records in whatever way best supports the use cases they are + designed for. + + ## Record Ownership + + It is the provider indicated inside each record that is the owner of the record, and not the + consumer registering it. This means that a consumer may be forbidden from registering or + deregistering a record for certain or all other service providers, even if it may register + and/or deregister records with itself as provider. + + ## Provider Identifiers + + Every service instance registered via this service interface _must_ be associated with a unique + identifier. In contexts where authentication is not used, providers _must_ chose their own + identifiers. Those identifiers _should_ remain consistent between restarts of those providers. + + ## Size Limits + + As a mitigation against denial-of-service attacks, all implementations of this service + interface _should_ reject incoming requests that are larger than a predefined limit. That limit + _must not_ be smaller than 8192 bytes for each received request. An implementation _may_ also + limit the sizes of individual parts within each request. It _must_, however, receive request + URI:s up to 2816 bytes in size, as well as request payloads up to 4096 bytes in size. + + version: 1.0.0 paths: /service-registry/list: