Release 2.8.0 was deployed to the production platform on Monday 28th June having been deployed to the customer integration/pre-production platform on Monday 7^th June. 

The workflow changes addressing error flows 1-7 and the persistent ID handling are described in the flow documentation.  Please refer to the link below for more information.

https://wiki.geant.org/display/InAcademia/InAcademia+Functional+flow+with+errors

The release comprises enhanced error handing to enable utilisation in merchants' decision making workflow:

Error: invalid or mismatching redirect_uri received: This change updates the workflow to redirect the user to error page: https://inacademia.org/error-redirect-uri/ when the RP provides an invalid or mismatching redirect_uri in a validation request.

Error: missing redirect_uri: This change updates the workflow to redirect the user to error page: https://inacademia.org/error-redirect-uri/ in the event that the validation request does not contain a redirect_uri

Error: invalid client_id received: This change updates the workflow to redirect the user to error page: https://inacademia.org/error-client-id/ in the event that the RP provides an invalid or mismatching client_id in a validation request.

Error: missing client_id: This change updates the workflow to redirect the user to error page: https://inacademia.org/error-client-id/ in the event that the validation request does not contain a client_id.

Error: invalid scope received: This change updates the workflow to redirect 'invalid_scope' to the redirect_uri with any of the following error descriptions:

• 'openid not in scope'
• 'Requested validation not allowed.'
• 'Requested validation of too many affiliations.'
• 'Requested both transient and persistent identifier.'
• 'The following scopes are not allowed: (INSERT SCOPE)'

Error: invalid or missing response_type: This change updates the workflow to redirect 'invalid_request' to the redirect_uri with either of the following descriptions:

• 'Response type is not registered'
• 'Missing required attribute+%27response_type%27'

Error: unsupported response_type: This change renames the error_message query parameter to error_description.

The release makes significant changes to the persistent identifier use case:

New ‘reuse detection’ feature: This change makes it possible for the merchant to include the ‘reuse_detection’ claim in its OIDC request, that will elicit a response from the InAcademia service containing a pseudonymised hash of the following supported persistent identifiers (provided they are received from the IdP) as a series of values that merchants permitted to use the persistent flow can utilise in order to recognise a returning user:

• eduPersonTargetedID
• eduPersonPrincipalName
• subject_pairwise
• eduPersonUniqueID
• Persistent NameID

This feature is available provided that the client_ID is configured for the ‘reuse_detection’ claim in the InAcademia backend. The persistent flow, returning the identifier as a sub (as versions up to and including 2.7.0), continues to be available.

Note that when Persistent NameID and  eduPersonTargetedID are returned by an IdP containing the same values, the hash values will also be the same in the reuse_detection claim.

Instructions for implementation: If you wish to utilise this feature, please send an email to support@inacademia.org to request the addition of the reuse_detection claim as an allowed claim for your clients. Upon confirmation that this addition has been completed, feel free to include the reuse_detection claim when initiating a validation request. You will receive a list of multiple possible identifiers and it will be necessary for the merchant to use those identifiers independently and in such a way that it is meaningful for the client. Please note that OIDC clients configured with this claim will only be permitted to use the persistent flow.

Replace error 13 with warning and provide transient ID in the event that persistent ID has been requested but cannot be constructed: Transient ID will be provided where persistent ID has been requested but cannot be constructed, instead of terminating in an error redirecting to the redirect_uri. The response will now include the relevant 'scope' parameter in the OIDC authorization response indicating the processed scopes, in accordance with OIDC specifications, confirming whether the identifier is transient or persistent, and is applied to both the transient and persistent flows. Examples follow below. Therefore, in the case when transient ID is provided to the RP instead of the requested persistent ID, 'transient' is part of the scope parameter instead of 'persistent'. This will allow merchants to detect this scope and configure its workflow to decide whether to proceed using the transient identifier or to request alternative validation. New persistent identifiers will be constructed for those created up to and including release 2.7.0.

Examples:

The release also includes the following features:

• Allow affiliations in uppercase: Where a SAML response from an IdP contains affiliations in uppercase, InAcademia will now allow affiliations returned from the IdP in uppercase, will no longer return the 'access denied: affiliation does not match' and will continue the validation of affiliations towards the merchant.
• Return transaction ID: id_token now contains a unique transaction identifier for the purposes of debugging.
• User consent screen translated to French.
• User consent screen now presents only the affiliation scope to be validated, not all scopes received.
• User consent: InAcademia privacy statement URL now opens in a new browser window.
• Further enhancements to internal logging and debugging capabilities.

References

The technical client implementation documentation: https://inacademia.org/oidc-implementation-for-inacademia/

Example client configuration for exiting client software: https://inacademia.org/client-rp-examples/

Implementation guidelines: https://inacademia.org/inacademia-implementation-guidelines/