ihe / it-infrastructure Goto Github PK

After committee review, and prior to public comment; we will move the content to a IHE managed github repo dedicated to IUA, away from the IT-Infrastructure repo. This will enable more clean management, issue tracking, and publication preparation.

There are no constraints on the content of the QEDm resources. It is good to have query parameters, but there are no constraints on the content. Such as requiring that Observations must use LOINC where ever possible. etc. See US-Core profile for some good baseline constraints. Is this lack of constraints intended or a missed opportunity to drive good quality FHIR Resource data?

Section 34.5 line 444 ff in IUA.b, Rev.1.2 from September 21, 2019 states:
The IUA requires that the Client Authorization Agent and client software shall meet the requirements of being an OAuth confidential client. The OAuth analysis indicates that without this requirement, the system is not sufficiently secure.

I suggest the change to:
The IUA profile requires the Authorization Client to meet the requirements of an OAuth 2.0 confidential client for security reasons.

Same sentences appear in Section 3.72.5.

Section 34.4.22 Line 405 in IUA.b, Rev.1.2 from September 21, 2019, states:
Users may delegate authority to:

It is not obvious to me, what is meant with authority.

In addition, one of the core concepts of OAuth 2.0 is, that the resource owner (user) explicitly authorizes applications to act on behalf by confirming the access right in a dialog.

The list of OAuth flows in Section 3.71 might be problematic, since

• the OAuth 2.0 Device Code Grant is missing, which would be my first choice for devices with no direct user interaction (monitors, etc.).
• according to OAuth 2.0 the client credential grant type is typically used by "clients to access resources about themselves rather than to access a user's resources".
• the implicit Grant Flow is no longer recommended by OAuth for security reasons.

In this bullet/paragraph:

• IT administrators are more willing to run their own internal authentication and authorization servers, but want to use off the shelf software and want the option to outsource these services. They are more likely to separate authentication from authorization than end user systems. Authentication issues are closely related to HR activities like hiring and firing. Authorization issues are related to patient and work assignments. These are controlled by different parts of the organization and have different process dependencies.

... I have bolded the sentence "They are more likely to separate authentication from authorization than end user systems" to show it in context.

Should this sentence be "They are more likely to separate authentication from authorization for (or with) end user systems"?

If not, please explain what this sentence is intended to convey, and I'll help clarify the wording.

in the Appendix A - Actor Summary Definitions the description of the Authorization Client Actor is missing the retrieving token behavior that shall support. The description should be something like:
A client that retrive access tokens and presents them as part of transactions.

It would be nice that there is a build script to build the doc and converts it to docx and pdf automatically. And that these will be available in a release bundle.

We could use for instance github actions for that.

Can I offer my help to make this happen?

Issue 3: Audit messages are only defined for clients that are also Secure Applications. There is no defined auditing for other clients.

Section 34.4.2.1 line 393 in IUA.b, Rev.1.2 from September 21, 2019, states:
The user communicates first with the authentication and authorization services to obtain an authorization token that will be presented to the resource service. This authorization token will be used as part of an access control decision by the resource service.
The User could be any kind of participant, and the resource use could be retrieval, query, or storage of a resource by means of HTTP transactions.

The first part of the statement is strongly misleading and conflicts with the core concepts of OAuth 2.0. There is no need for the client to communicate with the authentication services first. The Authorization Server instead must proof if the user is authenticated and redirect the client system to the Identity Provider, if not.

In addition, I strongly suggest to avoid the use of the term user in the second part of the statement.

The statement starting from line 311 states:
The JWT Token type and the SAML Token type enable the Resource Server to make additional Access Control Decisions.

This is misleading, because both are authorization or access token and as such, they may be used by the resource server to make Access Control Decisions.

"IT administrators are more willing to run their own internal authentication and
authorization servers, but want to use off the shelf software and want the option to
outsource these services. They are more likely to separate authentication from
authorization than end user systems. Authentication issues are closely related to
HR activities like hiring and firing. Authorization issues are related to patient and
work assignments. These are controlled by different parts of the organization and
have different process dependencies."

I suggest to modify the bold text.

Section 34.6, Line 461 ff states:
The Resource Server may also have such a list if there is a more precisely managed list of client_id and resource content access requirements. This can deal with resources that have more specific client requirements than the general access authorization requirements.

I don't see the need for this statement and strongly suggest to remove it.

Section 34.4.2.2.1 line 432 in IUA.b, Rev.1.2 from September 21, 2019, states:
In all cases, the authorization token identifies the device that is being authorized to perform the HTTP RESTful transaction and the patient involved, so that the appropriate access control decisions can be made.

As far as I know it's not the device which is authorized, but the application or app running on the device.

Section 34.5 line 445 in in IUA.b, Rev.1.2 from September 21, 2019, uses the wrong actor naming. It should use Authorization Client instead of Client Authorization Agent.

Section 3.71.4.1.2.3 uses a wrong actor naming: It should use Authorization Client instead of Authorized Client.

The IUA supplement has gone through some radical changes based on our current work item on IUA, and the regular call consensus. This is has resulted in a major rewrite of the supplement. I would like to get the ITI Tech membership to review the text over the next three weeks, and provide comments to resolve in October. The goal is to have a review-ready version for our November virtual-face-to-face meeting approval for formal Ballot. Thus this September review is not the formal ballot review, but rather the kind of review we do prior to going to public comment.

Given this is a radical rewrite, please comment on the whole document. Is volume 1 clear? is volume 2 clear? What questions does it leave you with? What more would you like to see? Are their sentence or spelling issues?

We request that your comments are submitted by September 25th. We realize this is competing with HL7 ballot and HL7 workgroup meeting.

We request that you enter your comments using GitHub Issues, would be glad to get some pull-requests too. (if you struggle with GitHub Issues, please just email your comments)
https://github.com/IHE/IT-Infrastructure/issues

The IUA supplement for review
https://github.com/IHE/IT-Infrastructure/blob/master/IUA.b/IHE_ITI_Suppl_IUA.md

The closed issues
https://github.com/IHE/IT-Infrastructure/issues?q=is%3Aissue+is%3Aclosed+

Line 305 ff in IUA.b, Rev.1.2 from September 21, 2019, states:
The SAML Token Option enables integration of environments that use both SAML identity federation and OAuth authorization infrastructure. This enables the end user to control authorization of applications through OAuth when the user identity authentication is already provided through SAML identity federation.

The statement is not correct: the IUA Authorization Server responds a authorization or access token, which is JWT or - in the SAML option- SAML 2.0. It may include identity claims, but it is no user identity assertion.

IUA restricts the applicability to confidential clients, which are able to keep client_secrets confidential. This excludes the use of IUA for Single Page Web Applications and Apps running on mobile devices. With PCKE OAuth 2.0 specifies an extension to the OAuth 2.0 authorization code flow to reach the same level of security for non-confidential clients.

Future versions of IUA should support the PCKE extension for non-confidential clients.

The statement in line 213 in IUA.b, Rev.1.2 from September 21, 2019, states:
IUA is not a substitute for documenting, establishing, and modifying these legal agreements. It is a method by which those agreements are enforced.

While the first part of the statement is obviously true, the second is not correct. IUA defines no method by which the agreements are enforced, but a method to retrieve and communicate claims used by other actors to enforce the agreements.

The statement starting from line 139 in IUA.b Rev 1.2, September 21, 2019 is misleading and may be wrong in its essence and shall be refined. The intention is not clear to me.

Currently it states:
The HTTP RESTful services may include user driven browser activity, downloaded applications, and automatic devices. The existing IHE ITI XUA Profile fills these needs for the SOAP transport based transactions. The existing IHE ITI EUA Profile fills these needs for various different transports within a single enterprise environment, including HTTP RESTful transports. The Basic Patient Privacy Consent (BPPC) Profile is associated with this profile and these other existing profile.

Section 34.1.1.3 states:

"Resource Server SHALL declare support for IUA in the capabilities endpoint using the element CapabilityStatement.rest.security. and the code "IUA" at system canonical URL "http://profiles.ihe.net/fhir/ihe.securityTypes/CodeSystem/securityTypes"."

Does this requirement hold even when the Resource Server does not expose FHIR APIs? It seems FHIR might be a common use case for IUA but IUA should be generic enough to work in any RESTful environment. Seems like it would be rather odd and possibly an undue burden to apply this requirement to a server that is RESTful but not FHIR.

Line 376 ff in Rev.1.2 from September 21, 2019, states:
The user can specify “use vendor X” to their healthcare provider.

The statement is generally not correct. In the Swiss EPR we rely in IUA, but would never allow someone to access health data authenticating with Google or FB. The user may select an Identity Provider accepted from the responding system instead.

The XDS wsdl files are 'incomplete' as they refer to xsd files not located in this respository

Line 391 in in IUA.b, Rev.1.2 from September 21, 2019, states:
A user with a mobile device wishes to retrieve a medical document to which they have authorized access.

It's not clear who or what is meant with they.

We need to define one or more vocabulary values to be used in the server CapabilityStatement to indicate that the rest server is using IUA profile. I have asked Grahame if IHE should manage a small codeSystem, or should just ask HL7/FHIR to create one or more vocabulary values for us. His opinion is that we should just ask HL7/FHIR to create them.

So, we need to determine what we would like these vocabulary values and descriptions would be. Do we need just one for IUA, or do we need more than one to represent the options within IUA?

Section 3.72.8.1:

A non normative example of the access token incorporation to a RESTful transaction is as follows:

GET /example/url/to/resource/location
HTTP/1.1
Authorization: IHE-SAML fFBGRNJru1FQd[...omitted for brevity...]44AzqT3Zg
Host: examplehost.com

This looks like a copy of the SAML token option rather than an example of the JSON Web Token option.

Line 368 ff in IUA.b, Rev.1.2 from September 21, 2019, states:
A user may interact with dozens of providers. It is difficult for the user to coordinate different authorization mechanisms with each of these dozens of providers.

The intention of the statement for the IUA profile is unclear to me and may cause misunderstandings. I strongly suggest to delete it.

Section 34.4.2.2 line 409 ff in in IUA.b, Rev.1.2 from September 21, 2019, states:
Applications that are distributed across multiple devices, or multiple instantiations, that are intended to act in a coordinated manner for a specific user. E.g., Kindle devices synchronize last read location, documents available, etc. across multiple Kindle devices for a single user account.

I don't understand the relevance of this example: On my kindle devices I had to log in to my Amazon account for the devices to have access

Issue 2: This profile mandates support for JWT token format. It has an XUA SAML Option defined by IHE for ease of integration with the IHE WS-Security environment. You may also use other token formats as part of a deployment.

Section 34.6, Line 461 in IUA.b, Rev.1.2 from September 21, 2019:
The XUA profile provides equivalent functionality for SOAP based transactions. In addition, the SAML token option in IUA enables an Identity Provider (Authorization Server) to exchange an XUA compatible SAML token for an OpenID Connect compatible token which can subsequently be used as an access token in all RESTful transactions specified in MHD, PDQm and other FHIR-based IHE profiles. The exchange of an XUA token for a JWT can take place without additional authorization, so it can be easily implemented by protocol translation gateways.

The statement is problematic in certain aspects:

• The first sentence is not complete and may lead to misunderstanding.
• There seems to be a confusion of the terms Identity Provider and Authorization Server. As far as I understand there is no relation between authentication and the IAU SAML option for the authorization.
• I don't see how the IUA profile supports to exchange an OpenID Connect compatible token to an XUA compatible SAML token.

CP-ITI-907-02_martins.pdf
A placeholder for changes as requested by CP 907

CP-ITI-907-02.pdf

[Edit: Hmmm. In reading through section 3.72, I now realize that the workflows defined in the IUA document do not follow the assertion frameworks proposed in RFCs 7521-7523, and my earlier comment was based on the mistaken assumption that those workflows were being followed (as used in UDAP, for example) so I have deleted the earlier comment and replaced with the following.]

In the current IUA workflows, the entity that provides the signed assertions is called the Authorization Server, but this is not the way this term is generally used in the OAuth 2.0 arena. As this actor is providing the assertions that contain the authorization metadata needed to make authorization decisions, then this actor is associated with the client and not the resource server. Other frameworks would call this the Client Token Service or Assertion Provider or something similar, but not call it the Authorization Server.

The term Authorization Server should represent the entity associated with the resource server that evaluates the assertions provided by clients to determine if an access token should be granted. Instead, the authorization token is presented directly to the resource server without a separate access token, such that the role of the Authorization Server (in the OAuth 2.0 sense) has actually been rolled into the resource server.

I see that how the IUA workflow does parallel how XUA is used in SOAP transactions, but this is not the way that FHIR/OAuth environments generally work. For example, the IUA model has not OAuth 2.0 token endpoint.

For example line 365 uses the word "can" for an option. The IUA profile should use the vocabulary of RFC2119 to avoid misunderstandings.

PDQm has a test case that recommends a 404. Do we mean it must do 404 and only 404? Or do we allow a 200 with zero results like the access control appendix allows? Would 200 with zero results be a good response too?

Section 34.2.1 in IUA.b, Rev.1.2 from September 21, 2019, states:
An Authorization Client , Resource Server, or Authorization Server that claims the SAML Token Option shall be able to use or generate the SAML tokens defined in the SAML Token Option. See ITI TF-2c:3.71.4.1.2.2 and 3.72.4.1.2.1.

As already pointed out in CP-907, one of the key features of OAuth 2.0 is, that the access token can be Authorization Client can be opaque to the client. Thus the client does not need to be able to generate or use the access token.

Same holds for Section 34.2.2.

Similar holds for Section 3.72.4.1.2 Line 673: As already proposed by CP-907 the client shall not validate the token.

to prevent name collision between multiple uses

Section 34.4.2.2.1 Line 422 ff in in IUA.b, Rev.1.2 from September 21, 2019, states:
The Incorporate Authorization Token transactions use an authorization token to indicate that this transaction is authorized. This token can be obtained by means of the Get Authorization Token, or by other methods.

This is misleading since:

• The authorization token communicates claims used to authorize the transaction (just like it is in XUA profile), it does not mean in any case that the transaction is authorized already.

Issue 1: This profile does not specify the internal structure of "client_id". This is a major concern for operations and security management. But, OAuth does not provide a full specification for client_id. It just specifies its purpose. DICOM's equivalent information attributes are: Manufacturer, Model, Software Versions, and Serial Number. The OAuth client ID must identify the device, the application (including any necessary version information), the particular instance, and any other information needed to identify the client application uniquely. Registration of clients is a significant operational and security problem that is being postponed until there is more experience with problems in the field and reasonable solutions. There is known danger from spoofing of client_id. At this time, the method for assignment of client_id is not included in the profile. In the field there are a variety of methods being tried. Many depend upon physical distribution methods or out of band communications to manage the authentication problems.

Some section headers, such as 3.71.4.1.1, appear smaller than the font used for normal paragraph text. This makes them easy to miss (especially when they appear next to images) and thus it makes it difficult for the reader to realize they are moving on to a new section.

The diagram in Section 3.71.4 uses wrong transaction naming.
It should read "Get Authorization Token Request" and "Get Authorization Token Response" instead of "Authorization Request" and "Authorization Response".

In Main Flow 1 of Incorporate Access Token, current text says "The authorization token may be an SAML token, a JWT Bearer token, or another access token type that is mutually agreed between Client, Resource Service and the token source."

The access token issued by the token source is not generally intended to be understood by the client and should generally be treated as an opaque string by the client to pass along to the resource server.

Recommendation:
remove "Client" from the list