RFC067: More flexibility in JSON Web Token attributes

Background and rationale

DSGO (DataStelsel Gebouwde Omgeving) aims to join iSHARE as a Data Space Governance Body and Participant Administrator. DSGO was initially developed on the basis of iSHARE, but additional requirements have lead to evolving specifications.

A fit-gap analysis identified differences between DSGO’s and iSHARE’s approach to JSON Web Token (JWT) attributes. DSGO uses signed JWTs for authentication and non-repudiation, requiring additional attributes that are not currently supported by iSHARE’s JWT header.

This RFC proposes extending iSHARE’s JWT attribute flexibility to accommodate DSGO’s requirements, ensuring alignment between both frameworks and enhancing interoperability.

Proposed change

Purpose

The current iSHARE JWT specification states that "Except from the alg, typ, and x5c parameter, the JWT header SHALL NOT contain other header parameters."

DSGO uses signed JWTs for authentication and for non-repudiation. In the latter case the DSGO JWT header differs from the iSHARE JWT header because of mandatory non-repudiation attributes b64, crit, sigD.

This restriction needs to be removed to allow additional attributes required for DSGO’s use cases, such as non-repudiation attributes (b64, crit, sigD) and the related_to payload attribute. This change will enable better flexibility and alignment between iSHARE and DSGO.

Additionally, DSGO defines addition payload attributeret: related to. iSHARE does not specify this attribute, although iSHARE does allow for additional payload attributes.

Considerations and requirements

DSGO proposes that iSHARE allows for these additional JWT attributes as defined by DSGO, in order to align both frameworks.

The iSHARE Foundation has explained that this requirement was inherited from earlier framework versions and today serves no purpose anymore, so it can safely be removed. There are no implications in terms of backwards compatibility.

Impact on the ecosystem

The following table lists the impact of this RFC on the formal iSHARE roles.

Formal role	Technical impact	Business / legal / functional / operational impact
Service Consumer	Potentially	No
Service Provider	Potentially	No
Entitled party	No	No
Authorization Registry	Potentially	No
Identity Provider	Potentially	No
Identity Broker	Potentially	No
Data Space Administrator	No	No
Participant Registry	Potentially	No
Data Space Governance Body	No	No

"Potentially" in this case means that the role could choose to implement other JWT attributes, whereas earlier this was not allowed.

Impact iSHARE Foundation (Scheme Owner)

• The iSHARE Trust Framework
• The developer documentation (as an extension of the iSHARE Trust Framework)
  • Remove the mentioned sentence on the iSHARE JWT specification.
• The OpenAPI definitions on Swaggerhub
• Example implementation in Postman Collections
• Code that is published on Github:
  • iSHARE Satellite reference implementation
  • eSEAL certificate procurement guide
  • iSHARE.NET service consumer core components
  • Python iSHARE package
  • iSHARE code snippets
  • Reference implementation for Authorization Registry
  • Reference implementation for Service Provider
  • Onboarding portal
• The implementation of the iSHARE satellite for iSHARE as the Scheme Owner on https://sat.ishare.eu and https://sat.uat.isharetest.net
• The public website
• Internal documentation
• Authorization Registry test implementation
• The Conformance Test Tool, tests listed on https://ctt.isharetest.net/admin/test-cases
• iSHARE test satellite (used for conformance testing): https://scheme.isharetest.net/
• iSHARE test certificate authority: EJBCA Public Web
• iSHARE Change Management documentation

Implementation

Release schedule

This RFC will either be released as part of iSHARE 3.0.

Communication

No specific requirements.