Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This part of the iSHARE scheme Scheme is considered normative and is therefore compliant with RFC 2119.

...

  1. 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.
  2. Delegation evidence is presented as a signed JWT. The signature of the Authorisation the Authorization Registry or Entitled Party provides proof to other parties.
  3. 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.
  4. A service from an iSHARE Service Provider MAY require a request to be signed.

...

Panel
  • 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 Authorisation 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

...