| Category/Priority | Description | Details/Notes | Source of Notes | Status |
|---|
| Authorization extension objects for additional use cases (B2B and beyond) | - This group doesn't need to create every authorization extension object that every sub-use case in the future might need
- What other claims are we missing?
- Claims that should be in STU 2 version of standard B2B object
- Claims that are not needed in every B2B use case that warrant being defined elsewhere
- Other authorization extension objects that we might want to add to the Security IG for other use cases beyond B2B
- Alternate workflow for authenticating patients for individual access requests in networks of networks for example
- One way is to use Tiered OAuth - user presenting and giving access to final data holder
- Other way is that these claims can be included in the whole authorization workflow without requiring patient to be clicking on things, explicit OAuth authorization every time - possible to include verified claims about a user in an authorization extension object submitted at time token request is made; obviates need for authorization endpoint interaction
- Consider for future Connectathons and possible integration into later versions of the IG
- Add AOE for identifying specific patient's resources or populations for token scoping.
| 2022-05-24 Security/UDAP Meeting
2022-09-13 Security/UDAP Meeting
2023-03-14 Security/UDAP Meeting |
|
| Include more detailed error responses in authorization objects | - Feature that we did not include in the STU 1 IG primarily for simplicity and ease of initial implementation
- OAuth errors from token requestors are uninformative and limited in their descriptions to some keys that are defined in OAuth
- Could provide a more detailed description re: something that's wrong with a particular authorization extension object
- There is a mechanism that you can extend the error response that comes back from OAuth when an extension object is used - error codes, descriptions, other fields that are defined as part of authorization extension object itself - we did not do this in STU 1, but can define associated authorization extension object errors
- Carequality has been looking at this to indicate more specialized responses around consent
- JV interested in exploring further
| 2022-05-24 Security/UDAP Meeting |
|
| Handling signed metadata assertions/certificates for multiple trust communities | Signed metadata in the response from the UDAP metadata endpoint has to be signed by a given certificate - those come from IETF, not from UDAP - restricted from including only one certificate in x5c header - if you happen to have 3 certs from 3 different trust communities, you have to choose one of them- If you want to have members of all 3 communities to access signed metadata assertion, how can I do it?
- Signed metadata assertion is a proof of possession assertion to make sure you're not just at the right server, but at the right endpoint
- Community A Cert, but actor from Community B that doesn't trust Community A - they won't be able to validate
- Could potentially extend in STU 2 if there are multiple communities that don't exchange cross-community
- Options
- Could use an array, but conflicts with RFC(?), so not really an option
- Could use built in UDAP certifications approach - as a server, provide certification for each community, and that's an array - but doesn't necessarily overcome the fact that signed metadata might not be trusted - might need an exception
- Could add a query parameter as optional
- Return default metadata if not included
- If included, the server, as a member of the identified community, would return a version of its metadata where signed metadata element is signed with a cert from that community; if it's not a member, it would have a choice to return what's most likely to interoperate, or a 404 (i.e., we don't support UDAP for that community)
- Carequality FHIR WG survey gathered feedback on this topic
- Add metadata element so a server can optionally advertise the community(s) of which its a member
- Add query parameter as optional
| 2022-05-24 Security/UDAP Meeting
2022-06-28 Security/UDAP Meeting |
|
| Certifications and endorsements | Carequality has worked on self-certification based on Epic's client app questionnaire for consumer facing apps - that trust community has been looking at a way to standardize and automate that; same questions could be digitally signed and answers submitted to other parties too. Could be formalized in STU2 or another standalone IG or profile within the IG. | 2022-09-13 Security/UDAP Meeting |
|
| Some items deferred from ballot reconciliation | FHIR-33651 - IETF clean up of OAuth, publishing docs for OAuth 2.1 (limited industry adoption since generally working with OAuth 2.0) - Look at backward compatible elements we might add to Security IG
- From Debbie Bucci to Everyone 02:12 PM - I would note that the IHE moblie profiles specifically mention the Oauth 2.1 draft. you may want to look a bit closer to see why
- LM participated in some of this early work - seemed they may be linking to whatever was latest version
- JL - we ended up pointing to both 2.0 and 2.1
- LM - could add to STU 2 - PKCE as best practice for authorization code flow
- Already an industry best practice, do we need to list again?
- ONC Cert program - servers must be able to support PKCE - voluntary update (SVAP)
- SMART 2.0 mentioned PKCE - all SMART apps must support PKCE
- JV - G10 - public client; PKCE added to Inferno test tool
- From Debbie Bucci to Everyone 02:23 PM - Oauth 2.1 is in IUA - so assuming portions of XUA are used today would be interesting to see where things evolve as that draft evolves . Maybe add this to notes
FHIR-33289 - allowing more information about id verification event to be included in the OAuth exchange (likely through use of additional authorization extension object) - Pass info besides user name and organization related to their session - when they authenticated, authentication level, etc.
- Expand object or create separate object
FHIR-33274 - expansion to universal realm | 2022-10-11 Security/UDAP Meeting |
|
| Public Apps - treated as if they can't protect a secret | - Run in browser (Javascript) - can store secrets via secure browser settings, but secrets are unreliable
- How to expand to take advantage of parts of UDAP framework
- Authorization extension objects - who signs them?
- developer
- Keys generated on device/ native apps - each installation could have its own keys
- Self-signed certificate - how much do you trust end-user and their device; how much value
- SMART community looking at how to do this using UDAP constructs
- Certifications - app developer might issue certification for installation of its app; developer can say it believe legit installation of an app; signed with trusted certificate from developer
- UDAP community also working on how to expand some of these concepts to public client that cannot keep a secret - not sure how much a role in healthcare beyond some consumer facing apps, but automated registration processes could be useful - entity/ app needs alternate way involving developer app providing a generalized assertion for its app installations - can't be as trusted as assertion from app security its own key, but better than having no secret at all - another area of discussion
| 2022-10-11 Security/UDAP Meeting
2022-09-13 Security/UDAP Meeting |
|
| UDAP Multi-hop | - Transitive trust model for obtaining access tokens or data
- Explored last year
- Beneficial in TEFCA environment? Apex hub with clients underneath communicating with Apex hubs
- OAuth and RESTful FHIR - same transitive trust approach instead of going point to point?
- Point to point more efficient from network resources utilization perspective - bottleneck if everything going through hub
- For data, wherever possible do point to point without going through 2 hubs
- Lower traffic, e.g., authorization, to get an access token could go through hub and then get data point to point
- Additional payload in the token request - routing object - everyone part of a network (QHIN) would submit outbound token request for entities outside their own network to a common outbound endpoint
- Routing object would indicate the ultimate FHIR server in the other network
- QHIN would validate token request, forward to next hub, re-signing with its own key, then next hub would transitively trust because coming from trusted peer QHIN, then pass to ultimate destination which would trust because coming from their trusted hub
- If hubs support UDAP protocol, there would be a way to reach the spokes beneath them using the transitive trust model
| 2022-10-11 Security/UDAP Meeting |
|
| Single-use authentication (dynamically generated token for one-time use) | - Use Case: Send info between 2 entities by reference – document reference as part of a transaction, which points to something on my system – one time authentication to retrieve it – once it’s been retrieved, can’t do again (authentication does not persist)
- e.g., pushing an unsolicited attachment
- Current method: Base 64 encode it and stick in document reference
- JSON Web token could be used – scope would constrain
- Service to subscribe to, purchase one token, accredited/ certified entity to provide them one at a time
- Wouldn’t want to create new security model for this, but a piecemeal way to access it, with all same security requirements to participate
- Several requests to the same org in one day, spec allows them to live for up to one hour – make 24 requests per day to get tokens for example
- Large orgs would prob want to sign their own tokens
- Would need to reconcile between approaches – UDAP, CDS Hooks, etc…
- Could be called out in Security IG - dynamically generated token for one-time use
- Channel it's transmitted on needs to be secured as well
- Seems like small subset of security model
- Idea: Add ref to RFC 6750 to cover passing Bearer token to resource access
- Idea: define “floor” of support for SMART scopes for B2B, B2C without necc biting off entire set
| FAST backlog workgroup submission 2023-02-14 Security/UDAP Meeting |
|
