the resource owner is prompted to authenticate to the resource authorisation server’s server (responsible for protecting the resource) once authenticated, the resource owner must consent to the permissions requested from the third party application client if approved, the authorisation server provides the application client with an access token the third party application client presents the access token when making requests to the protected resource. Central delegation across resources for party-to-party (person-to-person and sharing user controlled consent (UMA Protocol) – The diagram on page 9 depicts the five primary roles of resource owner, resource server, authorisation server, application client and requesting party, their relationships and domain boundaries. The roles are intended to work in an interoperable fashion where each is operated by an independent party (for example, different organisations). The notable differences to the single resource delegation model are: authorisation is managed centrally for multiple resource domains the central authorisation service may be provided by another entity chosen by the individual delegations can be managed/established at any time and ahead of time the requesting party (an individual or business) is known and can be authenticated (if required) The authorisation server will authenticate the resource owner, or may federate with an IdP for authentication. In this case, the OAuth-based OpenID connect protocol can be used as a means of collecting identity claims from a requesting party in order to attempt to satisfy the authorising user's access policy. The table below outlines some examples of central resource delegation and the respective actors of each role: Resource Resource domain/s Central Third party consuming domain owner authorisation Organisation Resource Organisation Application Requesting manager client party service Use case: A patient provides consent/authorisation for clinicians or healthcare providers to access their health record Patient Queensland Health MyGov Healthcare Medical Healthcare Health record provider Record provider or (e.g. system individual discharge clinician summary) Patient Healthcare Health MyGov Queensland Integrated Queensland provider record Health electronic Health or (e.g. medical individual discharge records clinician summary) (IEMR)
the resource owner is prompted to authenticate to the resource server’s authorisation server (responsible for protecting the resource) once authenticated, the resource owner must consent to the permissions requested from the third party application client if approved, the authorisation server provides the application client with an access token the third party application client presents the access token when making requests to the protected resource. Central delegation across resources for party-to-party (person-to-person and sharing – user controlled consent (UMA Protocol) The diagram on page 9 depicts the five primary roles of resource owner, resource server, authorisation server, application client and requesting party, their relationships and domain boundaries. The roles are intended to work in an interoperable fashion where each is operated by an independent party (for example, different organisations). The notable differences to the single resource delegation model are: authorisation is managed centrally for multiple resource domains the central authorisation service may be provided by another entity chosen by the individual delegations can be managed/established at any time and ahead of time the requesting party (an individual or business) is known and can be authenticated (if required) The authorisation server will authenticate the resource owner, or may federate with an IdP for authentication. In this case, the OAuth-based OpenID connect protocol can be used as a means of collecting identity claims from a requesting party in order to attempt to satisfy the authorising user's access policy. The table below outlines some examples of central resource delegation and the respective actors of each role: Resource owner Resource domain/s Central authorisation manager service Third party consuming domain Organisation Resource Organisation Application client Requesting party Use case: A patient provides consent/authorisation for clinicians or healthcare providers to access their health record Patient Queensland Health Health record (e.g. discharge summary) MyGov Healthcare provider Medical Record system Healthcare provider or individual clinician Patient Healthcare provider Health record (e.g. discharge summary) MyGov Queensland Health Integrated electronic medical records (IEMR) Queensland Health or individual clinician
5.-Federated-identity-blueprint-Process-models-v100.docx