Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

 

 

Client Registration

  1. The Server MUST allow for registration of Redirect URI (redirect_uris).  Per the OpenID Connect specification exact matching of Redirect URI is required to be performed by the Server.
  2. The server SHOULD allow for the registration of a public key by the client (jwks_uri or jwks) and a Token Endpoint Authentication method (token_endpoint_auth_method) of private_key_jwt but may support a method of  client_secret_jwt or client_secret_basic by returning a client secret with greater than xx entropy.
  3. Clients MAY indicate the required Authentication context “acr” as part of the client registration process or dynamically as part of a Connect Authorization request.
    1. Trust frameworks using this profile SHOULD use short names for Authentication Contexts that are registered in the IANA registry,   Full URI may also be used as names, but are not recommended.
  4. The Authorization Server SHOULD provide a way during registration for Clients to register the following:
    1. Authentication time claim in the id_token is REQUIRED:  (require_auth_time) True/False
    2. Maximum Authentication Age:  (default_max_age) Specifies that the End-User MUST be actively authenticated if the End-User was authenticated longer ago than the specified number of seconds. The max_age request parameter overrides this default value. If omitted, no default Maximum Authentication Age is specified.
    3. Default Authentication Context Class Reference (default_acr_values) An array of strings that specifies the default acr values that the OP is being requested to use for processing requests from this Client, with the values appearing in order of preference.

      OpenID Connect Dynamic registration is preferred for registering these values, but other out of band methods may be used, or the values may be provided dynamically as part of the authentication request.

 

2 User Consent

  1. Clients and Personally Identifiable Information (PII)
    1. The Authorization Server MUST prompt the Resource Owner to explicitly consent to the release of any claims or scopes requested by the Client.  
      The Authorization Server must not provide claims or scopes that have been declined by the Resource Owner. 
      The Authorization server MAY cache authorization for a client across sessions to avoid re-prompting the user for consent already granted.


Identity Assertions

  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. 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.
    2. Authentication Time: A timestamp indicating when End-User authentication last occurred.
    3. 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.


  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.

 

5        Directed Identity


  1. Clients may Discover if an Authorization server supports Directed identity by using Discovery and inspecting the "subject_types_supported" element in the meta-data.
    1. The Authorization server meta-data will list "pairwise" as an option if it is supported.
  2. The client MUST register a "subject_type" of "pairwise" per Section 2 of OpenID Connect Dynamic Client registration.
  3. The client SHOULD register a sector_identifier_uri per Section 2 of OpenID Connect Dynamic Client registration.
    1.  The sector_identifier_uri and its associated file of redirect URI is described in Section 5 of OpenID Connect Dynamic Client registration, and allow for multiple redirect_URI and clients to share the same Pairwise identifiers.

 

Error Response

The Authorization Server must respond with an HTTP 400 (Bad Request) response on authentication or authorization error and include a status as defined in the original OAuth spec section 5.2. Error Response

 

Security

1.     The Authentication Information Endpoint may be part of an existing API.

2.     The Authorization Server must provide a Scope that provides an Identity Assertion to the Client with only the elements from 2.

 

 

  • No labels