This page must be considered part of the iSHARE Framework
This page is considered normative and is therefore compliant with RFC 2119.
The following section describes the requirements for an iSHARE Signed JWT.
JWT Signing (JWS)
All iSHARE JWTs MUST be signed using the JSON Web Signature (JWS) standard which can be found at RFC 7515.
JWT Header
Signed JWTs MUST use and specify the RS256, RS384 or RS512 algorithm in the alg header parameter.
Signed JWTs MUST contain an array of the complete certificate chain that should be used for validating the JWT’s signature in the x5c header parameter, including the root certificate of the issuing CA that is listed in the iSHARE Trusted List.
Certificates MUST be formatted as base64 encoded PEM.
The certificate of the client MUST be the first in the array, the root certificate MUST be the last.
Except from the alg, typ and x5c parameter, the JWT header SHALL NOT contain other header parameters.
The iss and sub claims MUST contain a valid Party Identifier of the party that creates and signes the JWT (unless specified otherwise).
The aud claim MUST contain a valid Party Identifier of the party receiving the JWT.
The JWT MUST be set to expire in 30 seconds. The combination of iat and exp claims MUST reflect that. Both iat and exp MUST be in seconds, NOT milliseconds. See UTC Time formatting for requirements.
The JWT MUST contain the jti claim for audit trail purposes. The jti is not necessary a GUID/UUID. An new jti must be used for each JWT to avoid replay attacks.
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.
(3) iSHARE implementation is compatible with the following RFC extensions of oAuth:
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.
