Community+Feedback

include component="page" wikiName="siframework" page="RHEx Header" flat =How Can You Get Involved= There are various ways you can follow, provide feedback, or contribute to the RHEx project: =Community Feedback Repository= The following charts synthesize feedback the S&I community has made to the RHEx project team on our [|Google Groups] page and our WebEx meetings, and RHEx's response to each piece of feedback.
 * 1) Join the S&I Framework Wiki if you have not already done so.
 * 2) Read about the project on our wiki pages: Charter, RHEx Approach, Materials, Pilots, Related Efforts
 * 3) Subscribe to our Google Group and join the conversation (see the side bar on the right of the screen).
 * 4) Participate in WebEx meetings (see the side bar on the right side of the screen)
 * 5) View or contribute to our source code on [|GitHub].
 * 6) Contact Us for additional information.

Content Profile

 * ** Topic ** || ** Community Feedback ** || ** RHEx Response ** || ** Feedback Source ** ||
 * Direct Trust Framework || RHEx should take advantage of HISPs and the Direct Trust Framework to allow for distributed trust. || Profiling distributed trust between relying parties and idPs is out of scope for FY12. However, there is a difference between not being profiled and not being supported. The current Profiles do not preclude the use of such a mechanism and one could be layered on top of them. || [|Google Groups] ||
 * Schemas || How did RHEx come up with the schemas in the Content Profile? || The RHEx project team looked towards data already available – we didn’t want to try and reinvent the wheel. We looked at relevant use cases and reviewed existing data standards. Each procedure in the Profile has its own extension that relates to a schema. || [|WebEx] ||
 * RESTful Link || What happens after a RESTful link is clicked? || The goal would be for the user to see a full html view, but it depends on how the app wants to handle it. If the user looks at a patient record, they take the link from a Direct message and put it into critical software, then they could use JSON or Atom feed representations.The client and server will try to work out what is the best format that they can both support. In the future, there could be inbox processing on the Direct message so the client can pick the link out of the Direct message and request information straight from there. || [|WebEx] ||

OAuth 2 Profile
OAuth 2.0 Threat Model. || Gmail ||  || The RHEx approach attempts to free the enterprise from a single security domain. ||< [|Google Groups] ||
 * < ** Topic ** ||< ** Community Feedback ** ||< ** RHEx Response ** ||< ** Feedback Source ** ||
 * References for the Profile || It would be very helpful to justify and reference the OAuth2 Profile elements against the excellent IETF OAuth 2 Threat Model [] || RHEx is performing a security analysis of the OAuth 2.0 protocol using the Cryptographic Protocol Shapes Analyzer Tool. One of input considerations is the IETF
 * < Profile Algorithms and Minimums ||< It [the Profile] specifically calls out algorithms and minimum bit lengths, but doesn’t address the fact that these things minimums must increase over time to address the Moore’s law. ||< These profiles are meant to evolve and grow. The algorithms and minimum bit lengths are stakes in the ground to provide a baseline for the next iteration. ||< [|Google Groups] ||
 * < Mutual TLS vs. Server TLS ||< The use of “JWT bearer tokens” for authentication of the “confidential clients” seems sufficient to prove that a client is the owner of the OAuth 2.0 access token it receives from the authorization server, but seems highly inefficient. First, it requires implementation of an entirely additional authentication stack over top of what https:// (which is also required) can provide. Since public/private keys are already required to utilize the JWT tokens, it would make more sense to simply utilize mutual TLS (using either self-signed or externally issued certificates.) Doing so would offer protection from man-in-the-middle attacks that result from a single compromised server private key and/or root authority (the JWT approach offers no such protection). ||< One of the driving ideas for the RHEx project is to use the internet as it is used today for exchanging health information. Predominantly, the internet utilizes Server TLS over Mutual TLS. This is for a variety of reasons:
 * Mutual TLS is very difficult to deploy; requiring Mutual TLS would require all servers to know all clients
 * Mutual TLS tightly binds to a low level for the client.
 * Mutual TLS does not scale as well as Server TLS
 * < Revocation ||< Where correctly implemented, the client certificate approach could also provide a needed revocation mechanism (this document provides no such mechanism under the JWT approach – its presumed that manual revocation would be required with each service provider.) There’s also an overhead placed on the service provider from a performance perspective – it will need to implement either caching of JWT bearer tokens it receives or be forced to check the asymmetric signature of the token on each service call – there’s no mention/analysis of whether this is intended to be used with services that may have high transaction volumes and how it will perform. ||< Rather than employ revocation, RHEx allows us to make an HTTP query to see if the JWK is still there. The tokens themselves have built-in timeouts. We are investigating token introspection, to make an HTTP call to examine and validate the token. Fundamentally, PKI was built for a disconnected world. JWK was built for a connected world. ||< [|Google Groups] ||
 * < Profile Content ||< Technology choices aside, the specification doesn’t seem to offer any useful guidance on appropriate expiration lengths for JWT bearer tokens or how the JWT ID Claim would be used in an actual workflow (is it required because service providers are expected to require new signatures for every transaction, or only for certain ones?) ||< Yes, expiration lengths are in the profile. The JWT is an identifier for a token. Signatures are not transaction based – each new token is equipped with a new signature. ||< [|Google Groups] ||

OpenID Connect Profile
This actually gives us better protection than OpenID 2, which doesn't validate the key from the RP at all. Our profile makes that possible. || [|Google Groups] ||
 * ** Topic ** || ** Community Feedback ** || ** RHEx Response ** || ** Feedback Source ** ||
 * OpenID Connect Maturity || The OpenID Connect specification itself is still its infancy; while it has many advantages over SAML, maturity and stability are not amongst those advantages. || You are absolutely correct that OpenID Connect (OIDC) is still maturing. However, OIDC is being built by the same folks who built SAML and is based on OAuth2, which just achieved IESG approval. Based on this pedigree and wide use in industry, it is reasonable to expect OIDC approval by the end of this year. A key goal of RHEx is to chart a path forward, so we are aiming for where the target will be. || [|Google Groups] ||
 * Client Authentication || Client authentication given the use case is excessive. The OpenID Connect provider isn’t offering up any services or PII of the physician as part of the workflow (beyond their direct e-mail, which it’s assumed they would be providing); it’s only asserting an identity principal. Client authentication is only necessary when there is private information (such as information about themselves, or the ability to manipulate session) that the user wants to authorize a client to access on its behalf. || For mutual TLS it would be excessive, but our client authentication is lightweight. We have the possibility of using the basic shared secret, which is even lighter weight, but we are aiming for a higher NIST level of assurance of up to 3 for this use case. || [|Google Groups] ||
 * Client Authentication || Auth_time and acr (used to determine time and strength of authentication) should ALWAYS be evaluated by the client for correctness – authentication should not be required to ensure proper enforcement of parameters of the authentication request. || Great catch; we will update the profile to correct this. || [|Google Groups] ||
 * Profile Specs || While the proposed profile only allows for “code” and “code id_token” to be utilized, the OpenID Connect messages 1.0 specification requires that servers support “code”, “id_token”, and “id_token token” for interoperability purposes. To be properly spec-compliant, a burden is placed on the developer of the authorization server to support response types that won’t be used by the proposed profile. || We are further constraining the specification for the profile, and targeting a particular use case. We can allow for other response types; the profile is constructed to require that you have to answer to “code” and “code id_token”. || [|Google Groups] ||
 * OpenID Connect Complexity || OpenID Connect is significantly more complex than OpenID 2 for the given workflow as it introduces a SAML-esque discovery step to obtain signing material keys from the identity provider. These keys are used for public-key based verification of authentication assertions, similar to SAML. || True, OpenID Connect is more complex than OpenID 2 (OID2) but it is also more secure because of the back-channel. Even with this added complexity, it is still significantly simpler than SAML. || [|Google Groups] ||
 * Revocation || Hidden under the covers is the fact that there isn’t any revocation mechanisms for said keys, nor guidance on whether RP’s should cache them, fetch them every time, etc. etc. OpenID 2 direct verification can be much safer in this regard, as PKI revocation of the identity provider’s SSL certificate could stop an attacker whom has compromised a private key. OpenID Connect does offer direct verification similar to OpenID 2, but still requires the server to perform signature. The suggested profile also requires verification to occur by checking the token signature, and not the latter. At best, it’s overhead that can be ignored by RP’s using the code flow to obtain the id token directly from the server, at worst it’s as insecure as not checking for certificate revocation of the server you are speaking with. || The specification is built around tokens and the supporting mechanisms for obtaining, sharing, managing, refreshing and revoking tokens. The important thing is that the keys are not exchanged; they're fetched based on URLs that are exchanged. The endpoints house their own keys at their own URLs, which are protected by SSL certificates. Anybody fetching an HTTPS link is required to validate the server certificate. Here is how it works:
 * When the OpenID server (OP) fetches the OpenID client (RP)'s JWK, the RP is actually the HTTP server. So the OP must validate the server certificate of the RP when fetching the key.
 * Same but in reverse for the RP fetching from the OP.
 * Revocation || The same revocation concern applies to the client’s public key that is registered with each identity provider and required under the proposed profile || The public key URL is registered, not the key itself. Unlike passwords and certificates, tokens are built to be disposable and light-weight; they can be discarded, rotated (i.e. decrypt encrypted data with the old key and then re-encrypt it with a new key), and created fresh. || [|Google Groups] ||

RHEx Charter

 * ** Topic ** || ** Community Feedback ** || ** RHEx Response ** || ** Feedback Source ** ||
 * Scope || Patients need to be clearly noted as first class citizens in the Charter – it needs to be clear that patients themselves are authorized users and RHEx will support OpenID Connect by the patient as much as by licensed professionals || The scope of the RHEx project does not explicitly include any demonstration of a RHEx end-point transmitting data from one Relying Party to another. RHEx could support delivery of a payload consistent with what you describe for the transmission-scenario. RHEx does not preclude development of such functionality. We simply would not envision adding statements to our Charter that describe functionality beyond that which are planning to demonstrate and deliver. || WebEx ||
 * Scope || RHEx should address implementing consent || Implementing consent is out of scope for FY12. RHEx is built on OpenID Connect and OAuth, and exposes identical authentication and authorization functionality. RHEx allows for consent management systems in a Policy Decision Point architecture via the underlying OAuth 2.0 protocol. However, RHEx is an exploratory effort for Fiscal Year 2012, with a Phase 1 (Security) and Phase 2 (Content) scope. As such, consent or permissions management is not explicitly addressed by the FY12 RHEx project. || [|Google Groups] ||
 * Value Statement || The current value statement in the Charter is unclear. Are patients able to see, download and transmit the information as well as manage? || “Patient’s ability to manage health information” has been changed to “Patient’s ability to view health information” in the RHEx charter. || [|Google Groups] ||
 * Value Statement || The Charter should be restructured to reflect layering in the architecture and placement of the pieces of RHEx || To address this, RHEx proposes hosting a small working session where we would edit the charter as a steering group. We could then update the Charter tab on the S&I Framework RHEx wiki page, and manage further comments there or via this group. || [|Google Groups] ||
 * Stakeholders || Some portion of RHEx’s stakeholders should include exchanging administrative information || A particular user community would not be under served by the RHEx approach – testing to individual user communities would be out of scope for FY12. || WebEx ||

Other Feedback/Suggestions
=FAQ= If you have further questions about the RHEx project, please visit our FAQ page to see if it is answered there. If not, feel free to post on our [|Google Groups]page or send us an email.
 * ** Topic ** || ** Community Feedback ** || ** RHEx Response ** || ** Feedback Source ** ||
 * Related Efforts || RHEx should track related efforts || In response to this request, RHEx has developed a wiki page on related strategies, projects, profiles, and standards to the RHEx project. || WebEx ||
 * Direct Certificate Infrastructure || RHEx should leverage the Direct certificate infrastructure || RHEx thinks this is an excellent idea, but possibly out of scope for FY12. If there is enough bandwidth, RHEx will look into leveraging Direct’s certificate infrastructure. || WebEx ||
 * Securing Hyperlinks || RHEx should specifically highlight the need for a means to secure a hyperlink in a RESTful approach || To address this, RHEx proposes hosting a small working session where we would edit the charter as a steering group. We could then update the Charter tab on the S&I Framework RHEx wiki page, and manage further comments there or via this group. || [|Google Groups] ||