Correct (I think) -- explicit registration of all the resource sets and their associated scopes would put all the action in band for UMA, and thus not need the extension. In either case (explicit vs. implicit) the resulting RPT would (I assume) still explicitly mention the relevant scopes of the relevant resource set IDs for which access is being granted. That's sort of why I thought of the resource set ID challenge; it still needs to appear in the token. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Mon, Aug 1, 2016 at 12:14 PM, Debbie Bucci wrote:

I don't quite get why an extension would be needed in all cases for FHIR API.

API registers a resource set (foo) that include Fhir.resource type scopes - not necessarily multiple resources

- allergies read - allergies write - meds read - meds write

Could the RPT return a subset of scopes from the Resource set - using the profile as is today?

- allergies read - meds read

UI would need to react to scopes within a resource set not set up different resources. That's like .. .replicating the entire FHIR structure on he UMA server.

That doesn't preclude the desire to smaller resource set for other use cases.

On Mon, Aug 1, 2016 at 2:12 PM, Eve Maler wrote:

...

Last Thursday we got this far in our understanding about transferring standardized resource set and scope semantics (say, as captured in the FHIR API or some other large, complex API implemented by multiple independent service operators) out of band of the UMA RSR process:

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-28

The AS would declare that it's using the protection API extensibility profile, meaning that it's prepare to go outside the normal AS-RS communication route for some part of its interaction with RS's.

The community around the relevant API would define an extension profile. (We didn't talk about this, but such an extension profile would define an URI as an identifier, and this URI would be referenced in the AS config data/discovery document, advertising its compatibility with that profile.) The profile would, we believe, possibly involve explicit registration of a "bootstrap" resource that signals implicit registration of other resources that have standardized "type" fields.

It occurs to me that what's incomplete about this scheme (at a minimum -- there may be other things missing) is that, in explicit RSR, we register "instances" and not "types" of resource sets, and the RS gets back from the AS a specific resource set ID that has been dynamically created for it, and can't *tell* the AS what resource set ID it wants.

E.g., let's say that the RS registers a "bootstrap resource set" of "FHIR:EHR" type with the AS on Alice's behalf (and gets back a resource set ID of "foo"), which the HEART-UMA-FHIR profile defines as signaling that a whole bunch of other "sub-resource sets" of other specific types should be automatically registered too, like one with the "FHIR:medicationlist" type and one with the "FHIR:allergylist" type and whatever. What, exactly, are their resource set IDs in the Alice context? Since we had wanted to create these implicitly and not with an API call, how would the RS be informed of what these are? Or do we have to actually invent new bulk ways of doing this in-band?

(In a draft version of the RSR API, we used PUT instead of POST, which enabled the RS to dictate its own resource set IDs, but gave that up for very good reasons.)

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma