[Openid-specs-heart] HEART Scope Design Proposal #1

[Vivek Biswas]

I agree with Justin, that scopes are static string vs scope string be parameterized. Most of the OAuth server support static string. 

It will get challenging to implement a profile which requires dynamic string which in turn will hamper the adoption of HEART.

We are trying to add contextual information into the scope which are not what scopes are intended for.

Regards
Vivek Biswas, CISSP
Consulting member @Oracle 

> On Aug 9, 2016, at 9:17 AM, Justin Richer <jricher at mit.edu> wrote:
> 
> A problem I can see with this is that the “date” field in particular moves this from something that’s expressible as a table of known strings (like in the appendix of the current spec) to something that’s dynamically parameterized with a potentially infinite set of values. This is a problem in practice as many OAuth implementations treat all scopes as static strings, and will do things like limit set set of scopes a client is allowed to ask for based on a set of registered strings. That’s not possible with a field like “date” anymore, since the value is filled in at runtime. We tried to have parameterized scopes in BB+ (and even implemented it) but it was generally thought to be too complicated, and required special tooling at the authorizations server.
> 
> If at all possible, I’d like HEART scopes to not require such special processing and support at the AS.
> 
>  — Justin
> 
>> On Aug 8, 2016, at 9:08 PM, Adrian Gropper <agropper at healthurl.com> wrote:
>> 
>> Scope Design Proposal #1 aims to support a typical ROI authorization.
>> 
>> The structure of SDP1 is: patient/date/confidentialityclass/resource/edit
>> 
>> The logic is as follows:
>> /patient because this applies to only one patient at a time. The patient ID is local to the resource server.
>> /date is defined by FHIR and can be a range. Putting it at the highest level in the hierarchy (if a scope hierarchy is useful) allows for efficiency in clients requesting updates and reduces the cost to the resource server
>> /confidentialityclass filters for resources at or below the specified value. Resources that do not have a confidentiality class are considered N - Normal. It is up to the resource server to provide jurisdictictionally appropriate policies and user interfaces for setting confidentiality class other than N on particular resources.
>> /resource is any resource listed in the particular version of the FHIR specification
>> /edit is "read", "write", "any" operation by the client on the resource
>> A client might request a scope for immunizations for patient 23 as:
>> 
>> [ "date=le2016-8-8","conclass=N", "resource=Immunization", "edit=read" ]
>> 
>> on a resource registered as: [base]/Patient/23/ with a reference to HEART scopes SDP1 
>> that would tell both the AS and anyone else that dereferenced HEART/SDP1 that the RS would
>> process specific scope strings for date, confidentialityclass, resource, and edit as described above.
>> 
>> The AS would be free to present SDP1 to the RO any way that it chose.
>> 
>> A resource server like NYP that wanted to offer registration for sensitive data like Mental Health Treatment
>> would register another resource: [base]/Patient/23/MentalHealthTx with whatever scopes it offered. 
>> These additional resources would not be specified by HEART.
>> 
>> Any particular RS could choose to support Confidentiality Class, additional resources, neither, or both. 
>> 
>> It would be up to the AS to combine HEART SDP1 resources and additional resources and scopes offered by the RS into whatever policy setting experience it wanted.
>> With this scheme, an AS might offer Alice a policy setting for Observation = R - Restricted even on a resource server that did not support confidentiality class. This would cause all client requests for Observations to fail because the RS would be forced to treat unlabeled resources as N and the authorization tokens for observations were R. The RS could:
>> (a) ignore this problem and treat it as an AS bug, 
>> (b) implement confidentiality classification, or 
>> (c) offer additional resources and scopes so that the AS could tell Alice that Observations did not include those related to mental health in the hope that Alice would set Observation = N and deal with mental health as a separate part of her policy.
>> 
>> I believe that, to a first approximation, SDP1 would capture the functionality of most sharing use-cases without forcing the RS to do anything more than it is jurisdictionally already required to do. 
>> Adrian
>> 
>> 
>> 
>> -- 
>> 
>> Adrian Gropper MD
>> 
>> PROTECT YOUR FUTURE - RESTORE Health Privacy!
>> HELP us fight for the right to control personal health data.
>> DONATE: http://patientprivacyrights.org/donate-2/
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
> 
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160809/336fbe5a/attachment.html>