woutslakhorst
commented
4 years ago The signature contains personal information. Nuts will not, so I'll have to rethink some of proof that is present in the Cordapp and will be shared amongst nodes. This will not be an issue for the PGO node, since it will only receive the Hash of the signature not the signature itself. But the care nodes will store the signature, encrypted or not, it still contains personal data.
One option is to only add a reference to an endpoint where the signature can be found. If the signature is shared amongst care nodes, the then each must copy this reference and store it themselves with the patient records. The signature will not be viewable from the PGO, only from within the care organisation context.
This is a proposal on how to connect a PGO to health care context. This will allow a PGO user to login with an IRMA signature and use it to retrieve data from all connected health care organisations.
preconditions
PGO's need to be registered in the Nuts registry with a unique identifier and a public key.
reusing of existing standards
This proposal uses the Open ID Connect specification: https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication. All steps should be in line with the spec except when an access token is requested.
initiating authorization flow
The authorization step, which uses the OIDC authorization flow (https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth) can be initiated by a PGO. For the client_id, the global Nuts identifier will be used (available in the Nuts registry). For most care organisations this can be the AGB code, but for PGO's another identifier has to be found. (Mis-use by other parties of the client_id can be prevented by registering the redirect domains?).
user authentication flow
The user will be redirected to a page where it's asked to sign an IRMA contract stating the RP (PGO) will be allowed access given a certain scope and timeframe. The user will sign this with [BSN, initials, date of birth, birth name and e-mail address]. The IdP can then use the BSN to find patient records within their customers (allowing multiple connections at once for multi-tenant environments?). If IdP's do not support this then a tenant-dependent url is needed?
When patient records have been found, the user can select the health care organisations it wishes to get data from and the scope. There could also be an option to share the signature with other care organisations in the network.
authorization flow response
From the IRMA signature a Hash will be generated which will act as authorization code in the authorization flow response. Since it's a hash this code can be used for all token endpoints if those endpoints have received the IRMA signature as well (user opted to share with the network). This hash/code will be transfered via Corda to all involved nodes including the PGO node. The PGO node can link the response of the authorization flow to the user and the Corda state! This means that the PGO node is now a first class citizen in managing Nuts related data. This will allow the user to orchestrate some things from their PGO: manage their explicit consent or disconnect the PGO from the care.
access token flow
This used the standard OIDC flow for getting a short lived access token using the authorization token and private_key_jwt client authentication method. With one big catch: an additional claim in the JWT needs to be present representing the IRMA login contract the user signed when logging into the PGO. This is custom so we should investigate how this would work for the various vendors.
The resulting access token is then linked to the a virtual patient user in the XIS able to retrieve data about itself.
getting the data.
The PGO uses requests with the access token as bearer token. When the access token expires, the PGO can get a new one as long as the IRMA login contract is still valid.