No description provided.
Develop "final" conformance profile
Issue #1437
new
Comments (10)
-
reporter
-
reporter
These cases mostly have “Request only one claim“ without a definition of whether that is a clam requested at the basel id_token level of the structure or a claim that is inside “verified_claims.claims”
we should have tests that allow for both of those cases
-
reporter
Would it be possible to have a number of optional security profile options available in the “create a new test plan” without expanding the list of test plans so have a “OpenId Connect for Identity Assurance” test plan option that in turn has a range of security profile options? - Thinking beyond this - might it be possible to set up a “permissive” security profile that would allow OIDC4IDA to be tested with a wide variety of OpenID providers but not actively test the security profile, leaving that to a test plan that is focussed on security profile testing?
-
reporter
When testing OIDC4IDA the correct response to some requests depends on the end-user test data. Is it possible to have additional test plan input parameters that allow the person setting up the test plan to provide the end-user test identity claims and test identity assurance “verification” elements?
-
reporter
Is it possible to allow the person setting up the test plan to provide additional JSON schema that allows them to test their own specialisation of the Identity assurance response schema? This could be very useful for ecosystems that have decided to add constraints on how the IDA schema should be used in their context.
-
- For the “Request only one claim” tests, the request includes both verified and unverified claims. The tests looks at the OP metatdata for claims_supported and verified_claims_supported. It chooses one from the verified_claims and one from the unverified list ( which is generated by claims_supported minus verified_claims_supported). Unverified claims can be an empty list since claims_supported == verified_claims_supported, so there will be no unverified claims requested.
- For other security profiles, we discussed adding other configuration options e.g. PAR, sender constraint, etc so that it will work with other security profiles like FAPI
- For end-user data, the test ekyc-server-testuserprovidedrequest seems to do that already. The test is configured with expected response data and generates the necessary request parameters to get the desired response. It then compares the expected values vs the actual values received.
- Multiple schemas should be possible. I haven’t looked at whether the schema validator can accept a list of files but it it can’t I think we can just validate the schema files one by one.
-
The following 2 tests will be removed since the purpose field has been removed.
ekyc-server-long-purpose-invalid-request This test requests one known claim, selected from the list of claims_in_verified_claims_supported, with a purpose longer than 300 characters. The authentication request MUST fail and the OP return an error invalid_request to the RP.
ekyc-server-short-purpose-invalid-request This test requests one known claim, selected from the list of claims_in_verified_claims_supported, with a purpose which is only 2 characters long. As per section 6.1 of the spec, the authentication request MUST fail and the OP return an error invalid_request to the RP.
-
- For the security profiles, will be adding the following following configurations to the test plan using the options from FAPI (1&2)
- Sender Constraint (DPOP, MTLS)
- Client Authentication Type (Private Key JWT, MTLS)
- Auth Request Type (Simple, RAR) –> NOT YET
- Request Object Method ( PAR, by value)
- Request Method (signed non-repudiation, unsigned)
- Response Mode (plain, JARM)
- Client Type (Plain OAuth, OIDC)
- FAPI Profile (Plain, UK OB, Brazil OpenBanking, AU, KSA) –> NOT YET
Or add a ‘security profile’ option that will show different available options for for that profile
- End-user test data
- add configuration for requesting list of verified and unverified claims instead of using the first one in the supported claims list of OP metadata
-
Change to array data type to support multiple data sets
- ekyc_verified_claims_request
- ekyc_userinfo
-
Add configuration option for available OP end-user data
- verified claims response values will be matched with configured values
-
Support all optional elements in the schema? or subset?
- Will need to verify currently supported and unsupported options
- Any mandatory to implement claims which are optional in specs????
- Support other evidence types : electronic_record, vouch, electronic_signature (document is mostly supported)
- Add test cases for verified claims at the verified_claims.claims level in addition to id_token, userinfo
- Add support for addition JSON schema
-
Request and Response schemas will be array of text values
- Can potentially be used to validate/constrain ecosystem requirements/values
-
Will validate schemas one by one
- Remove attachments or keep??
- RP test plan → NOT YET
-
Do we need RP tests???
-
reporter
RP Tests is a good question let’s discuss with WG later today
- Log in to comment
List of beta tests from EdmundJ:
Here is a list of the current conformance suite tests :
ekyc-server-happypath Request only one claim, selected from the list of claims_in_verified_claims_supported without requesting any other verification element and expect a happy path flow.
ekyc-server-happypath-emptyobject Request only one claim, selected from the list of claims_in_verified_claims_supported, without requesting any other verification element and expect a happy path flow. Uses empty objects instead of 'null' when requesting claim.
ekyc-server-happypath-essentialfalse Request only one claim, selected from the list of claims_in_verified_claims_supported, without requesting any other verification element and expect a happy path flow. Uses {\"essential\": false} instead of null when request the claim.
ekyc-server-unknown-claim-omitted This test requests one known claim, selected from the list of claims_in_verified_claims_supported, and one random claim name (unknown to the OP) and expects a happy path flow. The unknown claim must be omitted from responses.
ekyc-server-unknown-essential-claim-omitted This test requests one known claim, selected from the list of claims_in_verified_claims_supported, and one random claim name (unknown to the OP), marked as essential, and expects a happy path flow. The unknown claim must be omitted from responses.
ekyc-server-unknown-claim-specialchars-omitted This test requests one known claim, selected from the list of claims_in_verified_claims_supported, and one random claim name (unknown to the OP), with special chars in its name, and expects a happy path flow. The unknown claim must be omitted from responses.
ekyc-server-one-claim-with-random-value-omitted This test requests one known claim, selected from the list of claims_in_verified_claims_supported, but with a random value (a UUID) that cannot be fullfilled and expects the authorization to succeed. The verified_claims must be omitted from responses completely as the value cannot be fulfilled.
ekyc-server-long-purpose-invalid-request This test requests one known claim, selected from the list of claims_in_verified_claims_supported, with a purpose longer than 300 characters. The authentication request MUST fail and the OP return an error invalid_request to the RP.
ekyc-server-short-purpose-invalid-request This test requests one known claim, selected from the list of claims_in_verified_claims_supported, with a purpose which is only 2 characters long. As per section 6.1 of the spec, the authentication request MUST fail and the OP return an error invalid_request to the RP.
ekyc-server-request-only-in-idtoken Request only one claim, selected from the list of claims_in_verified_claims_supported, only in id_token, without requesting any other verification element and expect a happy path flow. verified_claims must not be included in userinfo responses.
ekyc-server-request-only-in-userinfo Request only one claim, selected from the list of claims_in_verified_claims_supported, only in userinfo, without requesting any other verification element and expect a happy path flow.verified_claims must not be included in id_tokens.
ekyc-server-testuserprovidedrequest This test uses the verified_claims request provided in verified_claims_request field and expects a happy path flow, i.e the request must succeed.
ekyc-server-testbasedonuserinfo-defaults This test builds the verified_claims request using the userinfo data provided in test configuration and expects a happy path flow, i.e the request must succeed, and returned data must match the provided userinfo. This test will be skipped if userinfo data is not provided.
ekyc-server-test-userinfo-notfoundinop This test builds the verified_claims request using the userinfo data provided in test configuration and expects a happy path flow, i.e the request must succeed, and returned data must match the provided userinfo. This test will be skipped if userinfo data is not provided in configuration.
Of these tests, it looks like ekyc-server-long-purpose-invalid-request and ekyc-server-short-purpose-invalid-request are no longer relevant.
Some of the more advanced things like trust frameworks, evidences and documents are not tested.