Resource-Oriented Lightweight Information Exchange (ROLIE)

ROLIE deliberately avoids binding to specific data formats or information categories. Format agnosticism is achieved by having Entries declare their data model via rolie:format and by using IANA-registered extensible information type categories, allowing producers to support multiple isomorphic formats and consumers to select the most suitable one without protocol constraints.

security, http

The rolie:property element was introduced because atom:category, which uses scheme/term/label to represent categorical name/value pairs with a finite set of label values, is unsuitable for properties with unbounded values such as content-specific identifiers. A distinct element supporting arbitrary text values was necessary to represent such metadata.

http

A ROLIE Feed MUST contain one or more atom:link elements with rel='service' and an href attribute pointing to an Atom Service Document associated with the Feed, enabling discovery of additional content if a client accesses the Feed without first accessing the Service Document.

http

A standalone Entry MUST have an atom:link with rel='collection' and href pointing to the containing Collection URI. If the Entry belongs to multiple Feeds, it MUST have one such link per Feed. The Entry MUST also declare the information type of the content resource.

http, security

All member Entries in a ROLIE Feed MUST represent security automation information records of the provided information type category.

http, security

Any atom:category element whose scheme attribute uses an unregistered scheme MUST be considered 'Private Use'. Implementations encountering such a category MUST parse the content without error but MAY otherwise ignore the element.

security, registry

Any rolie:property element whose name attribute has 'urn:ietf:params:rolie:property:local' as a prefix MUST be considered 'Private Use'. Implementations MUST parse the content without error but MAY otherwise ignore the element.

registry

Clients that do not recognize a rolie:property element with an unregistered name attribute MUST ignore the element; the client MUST NOT fail parsing content containing an unrecognized property.

http

For an atom:feed to be a ROLIE Feed, it MUST contain only one child atom:category element with scheme='urn:ietf:params:rolie:category:information-type', and this category MUST have an appropriate registered term attribute value.

http, security

If a client encounters an unknown link relationship type, the client MUST ignore the unrecognized link and continue processing as if the unrecognized link element did not appear.

http

Implementations MUST support user authentication. A given implementation MAY allow authentication to be disabled on a Feed-by-Feed or workspace-by-workspace basis. Service implementers SHOULD support appropriate authorization checking for all resource accesses including individual Entries, Feeds, and Service Documents.

security

Implementations SHOULD prefer the use of registered rolie:property values over implementation-specific properties when possible.

registry

Link elements SHOULD be included in all Feeds to support paging using the 'first', 'last', 'previous', and 'next' link relation types per RFC 5005. Implementations SHOULD also support archive link mechanisms per Section 4 of RFC 5005.

http

The atom:updated element MUST be populated with the current time at the instant the Feed was last updated by adding, updating, or deleting an Entry, or by changing any Feed metadata.

http

The child atom:category elements in an app:collection's app:categories element MUST be the same set of atom:category elements used in the Atom Feed referenced by the collection's href attribute, ensuring category metadata is discoverable in both resources.

http, security

The server MUST implement certificate-based client authentication. This MAY be enabled on a workspace-by-workspace basis.

tls, security

There MUST be exactly one atom:content element in a ROLIE Entry, restricted to the atomOutOfLineContent formulation: the type attribute MUST identify the serialization type (e.g., 'application/xml') and the src attribute MUST be a dereferenceable URI for the content.

http

TLS version 1.2 MUST be supported. TLS 1.2 SHOULD be implemented according to all recommendations and best practices in RFC 7525. It is RECOMMENDED that the most recent published version of TLS be supported.

tls, security

When rolie:format appears, it MUST provide a 'ns' attribute identifying the data model of the resource referenced by atom:content. The URI used for the ns attribute MUST be absolute, though it need not be resolvable.

http, security

Correlating HTTP POST request timing against the atom:updated field can be used to profile users. This risk can be mitigated by using backend control of Feeds rather than HTTP POST when profiling is a concern. Cross-provider data correlation may also allow attackers to assemble datasets violating separation-of-duties policies; vetting clients at account provisioning is the primary mitigation.

privacy, security

The optional atom:author field may expose personal identifying information without consent if an Entry is published to a public Feed. When aggregating or programmatically generating ROLIE Entries, special care should be taken to ensure author personal information is not shared without consent.

privacy, security

A ROLIE Collection is identified within an app:collection by an app:categories element containing exactly one atom:category with scheme='urn:ietf:params:rolie:category:information-type'. A non-ROLIE Collection lacks this category, enabling mixed hosting of ROLIE and non-ROLIE collections in the same AtomPub instance.

http, security

The information type extension point uses atom:category with scheme='urn:ietf:params:rolie:category:information-type' to classify security automation information (e.g., incident, vulnerability, configuration checklist, software tag). Terms must be values registered in the IANA ROLIE Information Types registry.

security, registry

The rolie:format element describes the data model of the content referenced by atom:content. It carries a required 'ns' attribute (absolute URI identifying the data model) and optional 'version', 'schema-location' (URI of a validation schema), and 'schema-type' (media type of the schema) attributes.

http, security

The rolie:property element represents non-categorical metadata as name/value pairs in an atom:entry, where 'name' is a URI identifying the property and 'value' is unbounded text. It supplements atom:category for properties such as content-specific identifiers where allowed values are unbounded.

http, security

A new 'Resource-Oriented Lightweight Information Exchange (ROLIE) URN Parameters' top-level registry was created with Specification Required policy. Each entry records a Name of the form {type}:{label} (type is 'category' or 'property'), an Extension URI of the form 'urn:ietf:params:rolie:{name}', a Reference, and an optional Subregistry. Initial entries include category:information-type and four property entries.

registry, security

IANA registered the ROLIE XML namespace URI (urn:ietf:params:xml:ns:rolie-1.0) and schema URI (urn:ietf:params:xml:schema:rolie-1.0) in the IETF XML Registry per RFC 3688.

registry

The 'ROLIE Information Types' subregistry stores security automation information type values used as term attribute values in the information-type category scheme. Registration policy is Specification Required. Each entry records a Name (printable ASCII with embedded spaces), an IANA-assigned positive integer Index, and a Reference URI.

registry, security

A service discovery mechanism is not explicitly specified; implementations selecting one must ensure it provides a means for authenticating the server. DNS SRV records are noted as a possible solution. Additionally, distributed policy enforcement between source and destination systems risks unintended denial of service or information leakage.

security, dns

Primitive authentication mechanisms like HTTP Basic Authentication are rarely appropriate for sensitive ROLIE resources. Sharing communities handling sensitive data should adopt stronger approaches such as HOBA, SCRAM-SHA-256, OAuth with JWT, or SAML-based federated identity with multi-factor or risk-based authentication.

security

When using TLS 1.3, 0-RTT (Zero Round-Trip Time Resumption) should not be used to prevent replay attacks. An attacker could replay a stored PUT request to revert a resource to an older version, disrupting repository operation without the client's awareness.

tls, security