If the client's FHIR API call is a query that results in a patient-level resource or points to a specific patient ID, then these would be two examples of ways for "the resource server [to] derive [the necessary] information from the client's token-free access attempt". So the (so far, out-of-band) notification/invitation paradigms we've been discussing in HEART, where a link is generated and sent to the requesting party that their client can use for an access attempt, would suffice.

(Note that my most recent note in this thread is not about the UMA spec language per se, but rather about the RReg version of the language, which attempts to bridge OAuth, OIDC, and UMA uses of its framework.)


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


On Fri, Dec 30, 2016 at 12:57 AM, Adrian Gropper <agropper@healthurl.com> wrote:
The HEART folks have some trouble mapping to FHIR on account of this. I don't think we have a good example of FHIR resources in this context, do we?

Adrian

On Thu, Dec 29, 2016 at 6:26 PM Eve Maler <eve@xmlgrrl.com> wrote:
We have one more instance of wording similar to this in RReg:

In Sec 2.1 (rev 02), since this spec is meant to cover OAuth, OIDC, and UMA, under the uri property description we say:

"... Note: When a client attempts access to a presumptively protected resource without an access token, the resource server needs to ascertain the authorization server and resource identifier associated with that resource without any context to guide it. In practice, this likely means that the URI reference used by the client needs to be unique per resource."

Do we need to revise this at all to match the new UMA wording more closely, or does it suffice as a generic statement? I'm thinking it's close, if not entirely there.


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




On Mon, Dec 12, 2016 at 5:30 PM, Eve Maler <eve@xmlgrrl.com> wrote:
(Edited the subject line and will break up this thread into two for clarity...)

Excellent point about "single authorization server", thanks, Justin!

The other thing I was wondering about was: Everyone okay if we excise the other n instances of this explanation in the next section? As noted during our last call, now that the "normative commentary" about interfaces has largely moved to Section 1, I'd like to ensure that the messaging specifics are cleanly spelled out in the next section, with no holes and no "digressions" -- only xrefs back if we really want them.

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




On Thu, Dec 8, 2016 at 10:03 AM, Justin Richer <jricher@mit.edu> wrote:
For my action item from Eve’s post, I would suggest this wording:

Note: In step 3, the client attempts access to a protected resource with no token, and in step 4, the resource server requests permissions on behalf of that client at the authorization server. In order for the resource server to know which authorization server to approach and which PAT (representing a resource owner) and resource identifier to supply in that request, the API being accessed by the client needs be structured in such a way that the resource server can derive this information from the client's token-free access attempt. Commonly, this information can be passed through the URI, headers, or body of the client's request. Alternatively, the entire interface could be dedicated to the use of a single resource owner and protected by a single authorization server.



 — Justin







_______________________________________________

WG-UMA mailing list

WG-UMA@kantarainitiative.org

http://kantarainitiative.org/mailman/listinfo/wg-uma