SMART claims model

[Dunmail]

https://github.com/nhsconnect/gpconnect/blob/develop/pages/integration/integration_cross_organisation_audit_and_provenance.md

The SMART claims model predates FHIR and lacks some granularity; further, it was designed around the SMART use-case i.e. application integration on a per-patient basis. This limits its utility for managing claims on an API, e.g. when using operations. How do you permit Patient/12345/$foo but reject Patient/12345/$bar?

It is possible to use claims that map directly to the FHIR paradigm. For example: https://github.com/BlackPearSw/jwt-claims-fhir/blob/master/jwt-claims-fhir.md

[james-answer]

The current GP Connect JWT is only used for auditing of requests and not controlling what access a consumer has to a provider as the consumer creates the JWT.

This is probably more useful for consideration by the stratigic auth team as the stratigic auth solution will generate a signed JWT which will grant access to more specific resources by a consumer. This therefore might not be relevant at this time to GP Connect but may need to be passed onto the appropriate team.

[james-answer]

We are not going to be changing the JWT until the stratigic auth solution has been finalised and once it is we will not have control of the content of the JWT therefore from the perspective of GP Connect we are not going to do anything with this so we I am going to close the issue.

The stratigic auth team are aware of the options available and have been conducting planning on what access control they want to have.