GF Authorization #46
GF Authorization #46
Conversation
| **Trust Service Provider Certificates**: | ||
| PKIoverheid certificates. Used to identify the organization operating the client or server of data user or data holder. | ||
|
|
||
| **CiBG-DeZI**: |
| "resource": { | ||
| "type": "MedicationRequest", | ||
| "properties": { | ||
| "status": "active" | ||
| "patient": "90546b0d-e323-47f3-909b-fb9504859f7b" | ||
| } | ||
| }, |
There was a problem hiding this comment.
Is this data model the input for the policy, and/or as the PEP invokes the PDP?
Since if it's also what is sent to the PDP by the PEP, this resource means the PEP will be reading the EHR FHIR API to fetch this. If not, it's the PDP that has to read it.
| The action performed by the request. For example 'GET' (read/search), 'POST' (create) , 'PUT' (update). | ||
|
|
||
| #### Context | ||
| Other input for the policy evaluation is added to the context. For example the patient consents, OTV (Mitz) decision-outcome and the purpose-of-use (e.g. 'treatment', 'emergency' or 'research') |
There was a problem hiding this comment.
Do we need to distinguish the information model of the policy ('evaluation model'? not sure what the right term would be), and the data model (input and output)?
Because actually checking patient consent, can be part of the policy itself. Or, we keep that out of Rego (or at least the policy as defined here), and we implement it as sort of pre-evaluation step. E.g.:
- Receive policy evaluation request
- Fetch context (resource, context)
- Evaluate policy
- Respond with evaluation result
or
- Receive policy evaluation request
- Evaluate policy
2.1 Fetch context (resource, context) - Respond with evaluation result
|
|
||
|
|
||
| #### Scope | ||
| GF Authorization only specifies the input-variables, policy evaluation and output-variables of the authorization decision. ***How to obtain and verify the inputs, is out-of-scope***; other pages in this IG specify the use of authoritative sources, certificates and/or verifiable credentials. Execution of the request and architectural design (e.g. Policy Enforcement Point or AAA-proxies) are also out of scope. |
There was a problem hiding this comment.
don't we want to specify the wire protocol (what the PEP sends to the PDP and what it gets back in return)? Maybe informational/non-normative? To promote re-useable infrastructure components?
|
|
||
| ``` | ||
| { | ||
| "subject": { |
There was a problem hiding this comment.
I think this would be literally be the token introspection result, with registered claims
The build: https://build.fhir.org/ig/nuts-foundation/nl-generic-functions-ig/branches/authorization2/authorization.html