Add discovery for HealthWallet operations #16
Conversation
docs/index.md
Outdated
| @@ -201,7 +201,32 @@ openid://? | |||
| By using this URI-based approach, the lab can choose to display a static QR code printed on a sticker at the check-in counter, generating the signed request objects dynamically each time a client dereferences the `request_uri`. | |||
|
|
|||
| !!! info "Simplifying the workflow when a FHIR API connection exists" | |||
| If the Health Wallet app already has a FHIR API connection to the lab that includes the `__HealthWallet.*` scope, the app can begin an OIDC connection by invoking the `$HealthWallet.connect` operation: | |||
| A SMART on FHIR Server can advertise support for issuing VCs according to this specification by populating the following items in its CapabilityStatement, advertised at `GET /metadata`: | |||
There was a problem hiding this comment.
It'd be simpler just to have a property in our .well-known/smart-configuration.json file, instead of all this, huh?
There was a problem hiding this comment.
If the issue is aligning parameters between RP and SIOP, in SIOP v2 draft, the idea is to have a Relying Party (FHIR server in this case) pass registration parameters by value or by reference - if the Self-issued OpenID Provider (wallet in this case) supports those parameters the flow continues, if it does not support, the error is returned.
Including a parameter that indicates RP's support for VC issuance might be another option?
If the issue is broader and is about FHIR server advertising support for OpenID Connect itself, that's another issue. if SIOPv2 draft becomes adopted, advertising support for OIDC would be enough since did-siop would not be a separate extension anymore.
※I might be lacking FHIR specific context..
|
@Sakurann thanks for the question and comments. (I'm responding at the top level instead of inline because the inline thread I started is about a line that is no longer part of the change set for this PR.) The overall goal in #16 is to make it clear to any FHIR client whether a specific FHIR server is able to issue health cards (meaning the server supports the right sets of data and the right protocols to make this happen according to the smart Health cards spec). FHIR currently has a discovery protocol that allows clients to enumerate a capabilities of a server, so that is a natural thing to build on. Note that all of this happens before any SIOP request is generated, so any information that a server would be putting into the request is not visible to the client at this point. The FHIR client is going to use this discovery information to decide whether to call a FHIR operation on the server which initiates a request. |
|
This seems sensible to me and a low-risk change to the specification! +1 on merging this in. |
No description provided.