Authorization
The RO-Crate API uses an access property on each entity which signals to the
consumer that level of access the current user has to metadata and content.
This is designed to allow consumers of the API like Oni UI to communicate what
is accessible and redirect to enrollment URLs when access is restricted.
Access Property Structure
The API uses an access property to communicate access permissions. The structure differs between Entities and Files:
Entity Access Structure
Entities (Collections, Objects, and MediaObjects) include both metadata and content access controls:
{
"access": {
"metadata": true,
"content": false,
"metadataAuthorizationUrl": "https://example.com/apply?item=123",
"contentAuthorizationUrl": "https://example.com/apply?item=123"
}
}
Required Fields:
metadata(boolean): Whether the current user has access to view the entity's metadatacontent(boolean): Whether the current user has access to download or view the entity's content files
Optional Fields:
metadataAuthorizationUrl(string): URL where users can request access to metadata whenmetadataisfalsecontentAuthorizationUrl(string): URL where users can request access to content whencontentisfalse
File Access Structure
Files (accessed via /files endpoints) only include content access controls, as file metadata is always accessible:
{
"access": {
"content": true
}
}
Required Fields:
content(boolean): Whether the current user has access to download the file
Optional Fields:
contentAuthorizationUrl(string): URL where users can request access to content whencontentisfalse
Note: All examples in the sections below demonstrate Entity access patterns. For Files, only the content-related fields apply
Authorization Rules
Validation Requirements
When implementing the API, the following validation rules MUST be enforced:
- If
metadataisfalse, thenmetadataAuthorizationUrlMUST be provided - If
contentisfalse, thencontentAuthorizationUrlMUST be provided - Entities that violate these rules should not be surfaced in API responses
Implementation Flexibility
The authorization system provides maximum flexibility to implementors:
- Enrollment URL format: Completely open to implementor design
- Authorization flow: The process after visiting an enrollment URL is up to the implementor
- Access determination: How the API determines user access is implementation-specific
Access Scenarios and Examples
1. Full Access
Both metadata and content are accessible to the current user:
{
"id": "https://catalog.example.com/repository/PUBLIC/001",
"name": "Public Research Data",
"access": {
"metadata": true,
"content": true
}
}
2. Metadata Only Access
User can view metadata but must request access for content:
{
"id": "https://catalog.example.com/repository/RESTRICTED/001",
"name": "Sensitive Audio Recordings",
"access": {
"metadata": true,
"content": false,
"contentAuthorizationUrl": "https://ethics.example.com/apply?collection=RESTRICTED-001"
}
}
3. No Access
User must request access for both metadata and content:
{
"id": "https://catalog.example.com/repository/PRIVATE/001",
"name": "Confidential Collection",
"access": {
"metadata": false,
"content": false,
"metadataAuthorizationUrl": "https://portal.example.com/metadata-access?id=PRIVATE-001",
"contentAuthorizationUrl": "https://portal.example.com/content-access?id=PRIVATE-001"
}
}
4. Content Only Access
User can access content but not detailed metadata (rare scenario):
{
"id": "https://catalog.example.com/repository/CLASSIFIED/001",
"name": "Research Materials",
"access": {
"metadata": false,
"content": true,
"metadataAuthorizationUrl": "https://clearance.example.com/request?item=CLASSIFIED-001"
}
}
5. Invalid Configurations
These examples show invalid configurations that should result in errors:
// ERROR: content is false but no contentAuthorizationUrl provided
{
"access": {
"metadata": true,
"content": false
// Missing contentAuthorizationUrl
}
}
// ERROR: metadata is false but no metadataAuthorizationUrl provided
{
"access": {
"metadata": false, // Missing metadataAuthorizationUrl
"content": true
}
}
Client Implementation Guidelines
Checking Access
Before attempting to access entity metadata or content, clients should check the access property:
function canAccessMetadata(entity) {
return entity.access.metadata === true;
}
function canAccessContent(entity) {
return entity.access.content === true;
}
function getEnrollmentUrl(entity, type) {
if (type === 'metadata' && !entity.access.metadata) {
return entity.access.metadataAuthorizationUrl;
}
if (type === 'content' && !entity.access.content) {
return entity.access.contentAuthorizationUrl;
}
return null;
}
Handling Restricted Access
When access is denied, present the enrollment URL to users:
if (!canAccessContent(entity)) {
const enrollmentUrl = getEnrollmentUrl(entity, 'content');
// Display message: "Access restricted. Apply for access at: {enrollmentUrl}"
}
Use Cases
Public Archives
Most content publicly accessible with some restricted materials:
metadata: true, content: true- Open research datametadata: true, content: false- Culturally sensitive materials requiring approval
Institutional Repositories
Metadata discoverable but content restricted to authenticated users:
metadata: true, content: false- Internal research requiring institutional login
Sensitive Collections
Both metadata and content require special authorization:
metadata: false, content: false- Classified or highly sensitive materials
Implementation Notes
- Authorization URLs can point to any system: web forms, OAuth providers, institutional portals, etc.
- The API does not prescribe the enrollment process - this is entirely up to the implementor
- Access permissions may be user-specific, time-based, or dependent on other factors
- Consider caching authorization decisions to improve performance
- Ensure authorization URLs are accessible and provide clear instructions to users