OUTLINE: Materials Commons DSP Tier 2 (Identified and Controlled Access)¶

Status of this document¶

This is an outline, not a specification. It records the scope agreed for Tier 2 so that the boundary against Tier 1 is written down. No section below is normative, and the requirement language of BCP 14 is deliberately not used yet.

See the tier model for how the tiers relate.

Criterion¶

Endpoints are authenticated, catalogue content and access decisions may depend on the caller's identity or credentials, and policy actually constrains what a consumer may do.

Tier 2 is the first tier at which a contract negotiation can fail for a reason other than a malformed message. That single sentence is the test: if every well-formed request still succeeds, the deployment is Tier 1 with extra machinery, not Tier 2.

Included capabilities¶

Capabilities placed at this tier:

The contract negotiation and transfer process capabilities are not yet placed. Expected here: policy-based or manual approval of contract requests, and data-plane credentials in endpointProperties.

Excluded¶

Everything not listed above and not inherited from Tier 1. In particular the capabilities expected at Tier 3.

Open questions¶

• Prohibitions and duties may belong at Tier 3. They express usage control after access has been granted, which is beyond the Tier 2 criterion of controlling access.
• The filter language is undefined. DSP makes filter expressions implementation-specific, so a Materials Commons profile has to name one. JSONPath is proposed as the baseline any provider can meet, with SPARQL optional where a triple store already exists, and a mechanism for a catalogue to advertise which languages it accepts.
• Which authentication profile. OAuth 2.0 with signed JWT bearer tokens fills the extension point DSP leaves open, and the auth object has to carry a concrete protocol, version and profile. The exact values are not chosen. The profile also has to state what the token must assert, since DSP declares participant identity in the message payload and the authentication protocol in the version metadata without connecting the two: nothing in DSP requires the token's subject to correspond to the participantId it acts for.
• Which trust overlay, and it binds the whole data space. DSP leaves credential semantics to an overlay rather than defining them, in both directions: "All requests to HTTPS endpoints SHOULD use the Authorization header", which covers messages a provider sends to a consumer's callback as much as the reverse. The version metadata auth object is where a connector declares which overlay it speaks, and the specification's own example shows OAuth 2.0 and the Decentralized Claims Protocol as alternatives on an equal footing. DSP requires neither, and constrains participantId no further than a string.

The two overlays do not interoperate: a token from a shared authorization server and a self-issued token addressed to a decentralized identifier cannot validate each other, and DSP says nothing about token contents that would bridge them. The choice therefore binds a whole data space rather than an individual participant, and it decides which other data spaces a participant can ever exchange with. protocolVersions is a list with its own auth per entry, so a second endpoint speaking a second overlay remains expressible later. - Whether a provider must be able to state that it withholds nothing. That should not be expressed through the tier levels themselves.

Sections to write¶

Following the structure of the Tier 1 profile: conformance and requirement language; scope; terminology; normative namespaces; HTTPS service organization; version discovery including the auth advertisement; catalogue protocol including access-controlled content and filters; publication model including conditional offers; negotiation with policy evaluation; transfer with data-plane credentials; errors and status codes; security and privacy; state and lifecycle; extensibility; conformance checklist.