UDAP metadata example?

[Abigail Watson]

Hello, 
So, I've managed to get through ServerTest #16, and am now working on ServerTest #20, and getting some errors on the UDAP metadata.



You can access the UDAP metadata here:
https://vhdir.meteorapp.com/.well-known/udap

It clearly has an authorization_endpoint field. Can anybody help explain why this is failing, and how to resolve the error? Thanks!

Abigail Watson
Principal FHIR Software Engineer
Open Health Services, MITRE
awa...@mitre.org

[UDAP]

Hi Abigail,

For Test 20 (client_credentials) the authorization endpoint is not used, which is why "not applicable" is appearing; not applicable entries do not cause the parent test to be incomplete; you will need to look at the remaining tests that were not included on your screenshot.

This usually means that a later test is failing or cannot be completed that is preventing all of the IIB2 subtests from completing. Note that the test do not necessarily run in sequential order.

[Abigail Watson]

Let me revise my question... is the authz endoint the same as the authorization_endpoint? 

The documentation for this tool is pretty slim and the UI is terse, so it's not clear what the test runner is testing for, nor what I'm suppose to be doing here.  udap.org documentation references authz in the Mutual TLS Client Authorization page and Server Metadata page, but neither page mentions an endpoint.  Also, it would be extremely helpful if this tool were to display the URL calls that it's constructing and sending to our server.    

[UDAP]

Hi Abigail,

Yes, "authz" is an abbreviation for authorization and "authn" is an abbreviation for authentication. 

To expand on the Test 20 description on the main UDAP Test Tool Server Tests test page, the invalid requests are token requests that are almost identical to the final, valid token request in this test except that they contain parameters that should not result in a token being returned.

However, no token requests are made by the test tool at all if the test tool is unable to successfully register dynamically for a client_id for use with client_credentials, as is the case with the results in the screen shot you shared in the most recent message. Additionally, no requests are made to the authorization endpoint when testing the client_credentials flow. That's why the tool is marking that endpoint as N/A in this test.

The tool's design relies on the assumption that implementers are generally able to capture and log requests being made to or from their endpoints, such that it would be redundant for the tool's requests to also be displayed in its own user interface, however we are happy to make a note of your request as a potential future enhancement.

Thank you,
The UDAP.org Team

[Abigail Watson]

For what it's worth, abbreviations cause confusion for newcomers.  

Here is my ServerTest #16 showing successful passing of all tests.  Followed by ServerTest #20, stalling on step IIB4 with an unable to dynamically register to use client_credentials flow for remaining tests error.  

I'm on a hosted container-as-a-service environment, without root level access to the server, and just have access to the routes I define.  So if I don't know the URL that the information is coming in on, I can't log it and it just gets blocked by a firewall managed by the SaaS provider.  

How am I suppose to debug this if the URL isn't provided? 

[Abigail Watson]

So, digging into this error a bit more.... we see the timestamp of the registration error at 10:33:26.



Digging through the server logs in our hosting environment, and we find the software statement that's sent over at 10:33:26 as part of IIB4.  




When I send the software statement over by Postman, I receive an invalid_client_metadata error.  I've created a helper function that writes the criterion description along with the error, so we see that the JWT is missing a response_type, as per ServerTest #16 Criteria IIA4b4.  



But here we can see that we're passing step IIA4b4, and this error is expected.