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.)