This part of the iSHARE Scheme is considered normative and is therefore compliant with RFC 2119.
A JSON Web Token (JWT) is used when non-repudiation between parties is required. A statement, of which the data is encoded in JSON, is digitally signed to protect the authenticity and integrity of the statement.
iSHARE uses signed JWTs in the following ways:
In a request for an OAuth Access Token or an OpenID Connect ID token the client sends a signed JWT. The client is authenticated based on the verification of the JWT's signature.
Delegation evidence is presented as a signed JWT. The signature of the Authorization Registry or Entitled Party provides proof to other parties.
In a response from a server iSHARE metadata is presented as a signed JWT. The signature is used to bind the iSHARE metadata (such as license information) in the JWT to the content of the response.
A service from an iSHARE Service Provider MAY require a request to be signed.
On this page the generic requirements for a signed iSHARE JWT are specified.
For the payload of an iSHARE signed JWT the following requirements apply:
The JWT payload MUST conform to the private_key_jwt method as specified in OpenID Connect 1.0 Chapter 9 1 2
The JWT MUST always contain the iat claim
The iss and sub claims MUST contain the valid iSHARE identifier of the client 1
The aud claim MUST contain only the valid iSHARE identifier of the server. (Including multiple audiences creates a risk of impersonation and is therefore not allowed)
The JWT MUST be set to expire in 30 seconds. The combination of iat and exp claims MUST reflect that. See Dates and times for requirements
Depending on the use of the JWT other JWT payload data MAY be defined
Additional rationale
1 In OAuth 2.0 clients are generally pre-registered. Since in iSHARE servers interact with clients that have been previously unknown this is not a workable requirement. Therefore iSHARE implements a generic client identification and authentication scheme, based on iSHARE whitelisted PKIs.
2 Since OAuth 2.0 doesn't specify a PKI based authentication scheme, but OpenID Connect 1.0 does, iSHARE chooses to use the scheme specified by OpenID Connect in all use cases. This is preferred above defining a new proprietary scheme.
Example JWT payload:
{
"iss": "EU.EORI.NL123456789",
"sub": "EU.EORI.NL123456789",
"aud": "NL.KVK.12345678",
"jti": "378a47c4-2822-4ca5-a49a-7e5a1cc7ea59", // Note this is not necessary a GUID
"exp": 1504683475, // Equals iat + 30 seconds
"iat": 1504683445
}
Processing a JWT
A server SHALL NOT accept a JWT more than once for authentication of the Client. However within it's time to live a Service Provider MAY forward a JWT from a Service Consumer to one or more other servers (Entitled Party or Authorization Registry) to obtain additional evidence on behalf of the Service Consumer. These other servers SHALL accept the JWT for indirect authentication of the Service Consumer during the JWT's complete time to live
A server SHALL only accept a forwarded JWT if the aud claim of the forwarded JWT matches the iss claim of the JWT from the client that forwards the JWT
JWT contents that are not specified within the iSHARE scope SHOULD be ignored