Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FI-3460 Update registration success test description #11

Merged
merged 1 commit into from
Dec 5, 2024
Merged

FI-3460 Update registration success test description #11

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 18 additions & 7 deletions lib/udap_security_test_kit/registration_success_contents_test.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,14 +15,25 @@ class RegistrationSuccessContentsTest < Inferno::Test
> use by the Client App, the software statement as submitted by the Client App, and all of the registration
> related parameters that were included in the software statement.

[UDAP STU 1.1](https://hl7.org/fhir/us/udap-security/STU1.1/registration.html#request-body) clarifies that,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a link to version 1.1 of the spec, but above we're linking to version 1.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was intentional, but maybe warrants more explanation? I did so based on this Slack conversation between you, me, and Rob, in which you stated that you considered that update to HL7 UDAP STU 1.1 a clarification that we could account for in our STU 1.0 tests. To explain our updated test behavior, I linked the STU 1.1 source but did not explain the thought process behind the change for conciseness.

I could either omit the STU 1.1 reference and just keep the RFC 7591 reference, or explain why STU 1.1 is included, i.e., "Even though these tests are for STU 1.0, Inferno interprets this specific update in STU 1.1 as a clarification and therefore does not require all field values returned by the server to exactly match those submitted in the registration request's software statement."

in accordance with [Section 3.2.1 of RFC 7591](https://datatracker.ietf.org/doc/html/rfc7591#section-3.2.1):
> The authorization server MAY reject or replace any of the client's requested metadata values submitted during
> the registration and substitute them with suitable values.

This test verifies:
- `client_id` claim is included in the registration response and its value is not blank
- `software_statement` claim in the registration response matches the software statement JWT provided in the
original registration request
- The registration response includes claims for `client_name`, `grant_types`, `token_endpoint_auth_method`, and
`scope`, whose values match those in the originally submitted software statement
- If the registered grant type is `authorization_code`, then the response includes claims for `redirect_uris` and
`response_type` whose values match those in the originally submitted software statement
- `client_id` claim is present in the registration response and its value is not blank.
- `scope` and `client_name` claims are present in the registration response and their values are not blank.
- `software_statement`, `grant_types`, and `token_endpoint_auth_method` claims are present in the registration
response and their values match those in the originally submitted software statement.
- If the registered grant type is `authorization_code`, then the `redirect_uris` and `response_type` claims are
present in the registration response and their values match in the originally submitted software statement.

In order for downstream tests to succeed, it is
essential that the client and server are in agreement on the values of most of the software statement
parameters. The exception is `client_name`, which does not impact behavior. For this reason, an exact match
between the request and response values for `client_name` is not required.
Additionally, an exact match between `scope` request and response value is also not required because the
authorization server may grant different scopes than those orignally requested by the client.
)

input :udap_software_statement_json
Expand Down
Loading