Page Comparison

...

1.  The Authorization Server MUST utilize the method in Sec 3.1 of OpenID Connect Core to return an assertion to the Client. 
2. The Authorization Server MUST provide a JWT id_token which provides the following claims to the Client about the individual granting authorization (Resource Owner).
   1. Issuer Name:  “iss” The domain of the Authorization Server such that when paired with the user identifier creates a globally unique identifier. 
      1. The issuer name SHOULD be an https: scheme URI and MUST be under the control of the Authorization Server.
   2. User Identifier:  “sub” A persistent identifier for the Resource Owner granting authorization to the Client to access the authentication information endpoint. 
      1. The User Identifier MUST be a unique, opaque and not re-assignable identifier for the user. 
   3. Audience Restriction:  “aud” specifies the Client for whom the identity information is intended. 
      1. The Audience Restriction MUST be the client_id of the Client requesting the authentication.
   4. Issuance Time Stamp : “iat” The time that the Authorization Server issued the identity assertion.
   5. Expiration Time Stamp: "exp" The time after which the JWT must not be accepted for processing.
      
   6. Nonce:  “nonce” A value tying the identity assertion to a browser session.  This MUST be present if the client provided a nonce value in the request. 
3. The Authorization Server SHOULD include the following claims in the Identity Assertion:
   1. Expiration Time Stamp: The time after which the identity assertion is no longer valid.
   2. Authentication Context: The Authentication Context Class reference for the authentication event.
      1. If the Client request Authn Context during the registration process, or requested it via the Authorization request, the Authz server MUST include it in the response.
   3. Authentication Time: A timestamp indicating when End-User authentication last occurred.
   4. JWT ID: "jti" A unique identifier for the id_token. 

1. The Identity Token MUST be digitally signed.
   1. The Identity Token MAY be digitally signed using a FIPS-140 approved algorithm (e.g. RSA or ECDSA) using a trusted key.The Identity Token MAY be digitally signed using an HMAC with the Client Secret.  (I don't think that any large IdP are going to be dong symmetric signing, so this is probably not worth including)
      
      
      
2. The Identity Token MAY be encrypted for the Client.
   
   
3. Clients MUST verify the integrity and authenticity of the Identity Token per Section 3.1.3.7 of OpenID Connect Core.

...