[Openid-specs-ab] 2024-02-08 Connect working group call notes

[Tom Jones]

Certainly! *Azure* provides support for *SMART on FHIR*, which is a
healthcare standard enabling applications to access clinical information
through a data store. Here are the key points:

   1.

   *What Is SMART on FHIR?*
   - *SMART on FHIR* combines open standards like *OAuth2* and *OpenID
      Connect* with *FHIR interfaces*.
      - It allows applications to securely integrate with *Electronic
      Health Record (EHR) systems* and access clinical data.
      - By adding a security layer, it ensures authentication and
      authorization for FHIR repositories
      <https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/smart-on-fhir>
      1
      <https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/smart-on-fhir>
      2
      <https://learn.microsoft.com/en-us/azure/healthcare-apis/azure-api-for-fhir/smart-on-fhir>
      .
   2.

   *Benefits of Using SMART on FHIR*:
   - *Authentication and Authorization*: Applications have a known method
      for obtaining authentication and authorization to a FHIR repository.
      - *Restricted Access*: Users accessing a FHIR repository via SMART on
      FHIR are limited to resources associated with their user profile.
      - *Granular Data Access*: Users can grant applications access to
      specific subsets of their data using SMART clinical scopes
      <https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/smart-on-fhir>
      1
      <https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/smart-on-fhir>
      .
   3.

   *Setting Up SMART on FHIR with Azure*:
   - *Prerequisites*:
         - An instance of the *FHIR Service .NET SDK 6.0*.
         - *Cross-Origin Resource Sharing (CORS)* enabled.
         - A registered *public client application* in *Microsoft Entra ID*.
         - Access to an *Azure Subscription* for creating resources and
         role assignments.
      - *Steps*:
         - Set up the *FHIR SMART user role* to manage user access.
         - Integrate the *FHIR server* with other Azure services using
         *samples* (such as APIM, Azure Functions, etc.)
         <https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/smart-on-fhir>
         1
         <https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/smart-on-fhir>
         .
      4.

   *Note*:
   - The *open-source FHIR Server for Azure* includes a simple *SMART on
      FHIR app*
      <https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/smart-on-fhir>
      1
      <https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/smart-on-fhir>
      3
      <https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/overview>
      .
      - These samples are not part of the *Azure Health Data Service* and
      are not officially supported by Microsoft
      <https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/smart-on-fhir>
      1
      <https://learn.microsoft.com/en-us/azure/healthcare-apis/fhir/smart-on-fhir>
      .

In summary, Azure supports SMART on FHIR, allowing secure integration of
healthcare applications with FHIR data repositories.
FROM THE BING COPILOT!!!! ..tom


On Thu, Feb 8, 2024 at 3:15 PM Tom Jones <thomasclinganjones at gmail.com>
wrote:

> i guess i should have noted that I was the one to connect FHIR devs, one
> of whom works for Microsoft. ..tom
>
>
> On Thu, Feb 8, 2024 at 3:11 PM Tom Jones <thomasclinganjones at gmail.com>
> wrote:
>
>> Mike - the reason to go to oidc 1.1 is that we expect RSA to be
>> deprecated this year - and oidc requires it.
>>
>> ..tom
>>
>>
>> On Thu, Feb 8, 2024 at 7:47 AM Joseph Heenan via Openid-specs-ab <
>> openid-specs-ab at lists.openid.net> wrote:
>>
>>> Attendees:
>>>
>>> Joseph Heenan
>>> Michael Jones
>>> George Fletcher
>>> Bjorn Hjelm
>>> Brian Campbell
>>> David Waite
>>> Filip Skokan
>>> Pamela Dingle
>>>
>>>
>>> Only 3.5 weeks left to make submissions for IETF
>>>
>>> *Native SSO*
>>>
>>>
>>> https://bitbucket.org/openid/connect/issues/2101/native-app-sso-no-prescriptive-restriction -
>>> George to raise a PR
>>>
>>>
>>>
>>> https://lists.openid.net/pipermail/openid-specs-ab/2024-February/010226.html -
>>> George will respond on the list
>>>
>>> *Federation*
>>>
>>> https://bitbucket.org/openid/connect/pull-requests/695 - Conflicts
>>> resolved, Mike plans to merge.
>>>
>>> Mike & others spoke with Stefan Santesson about the federation issues he
>>> had raised, which seemed to come down to potentially not trusting RPs to do
>>> key management. A productive discussion was had and Mike plans to close
>>> many of the issues.
>>>
>>>
>>>
>>> *POST at authorization endpoint*
>>>
>>> Joseph noted there was further discussion on
>>> https://gitlab.com/openid/conformance-suite/-/issues/1293 that should
>>> be happening within the Connect working group instead.
>>>
>>> Mike asked Joseph to open an issue in the connect tracker, which Joseph
>>> did:
>>> https://bitbucket.org/openid/connect/issues/2115/post-to-authorization-endpoint
>>>
>>> Brian noted that Ping does accept POST on the Authorization Endpoint.
>>>
>>> There was general discussion about adding conformance tests vs
>>> discouraging this is the spec, and noted that FHIR spec requires the
>>> authorization server support this as per Aaron’s original message, that if
>>> we were encourage people to implement POST it’d be better to push them
>>> towards PAR.
>>>
>>> An errata can’t make a normative change to the current requirement in
>>> OpenID Connect to support POST at Authorization Endpoint.
>>>
>>> Mike said a 1.1 for this would be overkill. Pam asked if there’s
>>> anything else that would go into 1.1. Filip suggesting returning access
>>> tokens from the Authorization Endpoint could also be removed. Mike said he
>>> wouldn’t want to start 1.1 while the ISO PAS submission was ongoing, which
>>> may take 9 months.
>>>
>>> George suggested adding a conformance test that only issues a warning if
>>> it fails, and also creating a new conformance profile that requires it be
>>> supported as per FHIR.
>>>
>>> Joseph asked if FHIR intend to use our certification tests. No one knew.
>>> Mike J suggested it would be worth discussing again on a call where Aaron
>>> was present.
>>>
>>>
>>> *Moving to github*
>>>
>>> Pam asked if everything is moving to GitHub. MikeJ said it’s been
>>> handled on a case by case basis, and e.g. the Federation authors would like
>>> to move to GitHub once they have some existing issues & PRs closed (as the
>>> PRs/issues do not transfer over well).
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20240208/db8038c8/attachment.html>