[Openid-specs-heart] How do you define a resource set?
eve.maler at forgerock.com
Thu Jul 7 00:20:18 UTC 2016
Thanks to Debbie for digging into the precise UMA spec text
that's relevant for resource set and scope profiling; it's the spec called
"OAuth Resource Set Registration". This is one big area that's relevant for
us to profile for interoperability -- as Justin said:
*"...it’s up to the API definition (FHIR in our case) to decide what
actually goes into the sets themselves. It’s up to either the API
definition or a security profile (like what we’re doing here in HEART) to
define the mapping between scopes and resulting actions/data. But it’s
always up to the RS to enforce these."*
Because we're dealing with a standard API, and a standardized mechanism for
RS-AS interaction, but not (yet) a standard for resource set dividing lines
or scope semantics, that's where we/HEART come in.
If you look at Sec 2.1
Resource Set Descriptions, the fields we could possibly populate in each
case of a standardized FHIR resource set for HEART/UMA are:
Note that an RS registers a specific resource set in the context of a
specific resource owner (such as Alice), and the name and icon_uri fields
are meant to be UX hints for resource owner tasks such as setting policy.
The type field is related to the semantics of of resource set (that is, its
"class"). and its set of scopes (which are listed by reference) can
obliquely be seen as related to its semantics too.
The fields we could possibly populate in each case of a standardized scope
for HEART/UMA resource sets, as described in Sec 2.1.1, Scope Descriptions
A few additional notes:
Scope descriptions in particular, while they don't have a type field on
them, were designed to be possible to reuse. If the scope string "called"
from a resource set description is a URL vs. a string (a la OAuth), it's
meant to be retrievable as a JSON document, and it could be retrieved from
some third-party source if it's desired to reuse someone else's
standardized scope definition. You could publish whole libraries of them.
UMA was designed to enable extension wherever needed; we readily "admitted"
that if something wasn't originally thought of, JSON properties could be
added. Third-party extensions to meet such needs are easy to write.
If additional metadata describing various properties of scopes or resource
sets (such as data confidentiality levels or whatever) were desirable,
those might be good use cases for HEART defining extensions. I don't
imagine that confidentiality would be a *primary* resource set semantic,
*It's up to us to figure what "grain" to make the resource sets.* FHIR goes
"all the way down" in its XML and JSON representations. I suspect HEART
need not, and can be use-case-sensitive because of our patient centricity,
but this may be the central question for us to discuss before digging in.
*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
*ForgeRock Summits and UnSummits* are coming to
<http://summits.forgerock.com/> *Sydney, London, and Paris!*
On Sat, Jul 2, 2016 at 10:21 AM, Debbie Bucci <debbucci at gmail.com> wrote:
> These profiles will not be like DAF or USLab or QiCore; but will be a
> layer added to these. This layer will be agnostic to the underlying data
> profiling layer.
> Are you referring to something like ...
> https://www.hl7.org/fhir/profilelist.html ?
> Hence why I recommend HEART simply adopt either the SMART scopes or the
>> _confidentiality codes.
> I was going to include SMART in potential example but did not see a direct
> reference to the profile on HL7 - though generally understood I suppose.
> Any talk by other groups wanting to implement SMART seem to focus on the
> resources that lead back to DAF ... and given the examples in the profile
> (pasted below) I assumed that all resources could have separate access
> Scopes can be used to indicate access to different kinds of things in an
> API. Common examples include:
> - The kind of resource being protected (medications, appointments).
> - The kind of access to the resource being requested (read, write,
> - The specific resource being accessed (user ID, resource URI).
>> The _confidentiality codes are in my view closer to a useable set, and
>> are not specific to FHIR. But the SMART scopes are being used in
>> demonstration systems and are not out-right-wrong. The important part is
>> that the scopes we include need to be recognized as a starter-set, that the
>> actual scopes we will find in production are likely to be totally different.
> SMART AND Confidentiality codes seems like good combination to start with-
>> You can continue to ignore me...
> Not ignoring - just ignorant. REALLY trying to put the pieces together.
> Can't help the process along if I don't understand.
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-heart