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 wrote:

We have one more instance of wording similar to this in RReg:

In Sec 2.1 https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-02.html#res... (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 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 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Thu, Dec 8, 2016 at 10:03 AM, Justin Richer 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

I think FHIR has more than one way to specify a resource for a single patient and this would be true of other APIs beyond healthcare. It would be incredibly helpful if UMA gave examples of the specific ways FHIR does this. Adrian On Fri, Dec 30, 2016 at 4:04 PM, Eve Maler wrote:

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 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Fri, Dec 30, 2016 at 12:57 AM, Adrian Gropper 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 wrote:

...

We have one more instance of wording similar to this in RReg:

In Sec 2.1 https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-02.html#res... (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 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Mon, Dec 12, 2016 at 5:30 PM, Eve Maler 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 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Thu, Dec 8, 2016 at 10:03 AM, Justin Richer 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

-- 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/

IMHO, we'd be foolish to ignore the specific example of FHIR before we put UMA.next to bed. Adrian On Fri, Dec 30, 2016 at 4:28 PM, Eve Maler wrote:

UMA can't do this for every UMA-protected API because this is where the APIs' semantics come into play; it would behoove API publishers, especially those of public/standard/implemented-by-more-than-one-party APIs, to document this themselves.

Note that there's another clause that's relevant, from Core Sec 1.4.3 rev 09 https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-09.html#resource-serv...; see the bold part: "Any one resource that the resource server has registered for protection MAY consist, from the resource server's perspective, of multiple parts, or have dynamic elements such as the capacity for querying or filtering, or otherwise have internal complexity. It alone is responsible for maintaining the necessary mappings between these complex representations *(which might be expressed, for example, as different requests coming from the client)* and the single resource identifier known to the authorization server."

We had a version of this in UMA1, but based on experience (FHIR being one of the more complex APIs -- "there's more than one way to do it!" :-) ), we sharpened it up a lot more. (Rev 10 will change it to active voice.) The client only knows the API and what they're trying to accomplish, but don't know resource IDs. The AS only knows what resources get registered. The RS (API publisher) is the only thing that can keep tabs on the correlation, in the sense of a) what resource, b) what resource owner, and c) what authorization server to go with when the client shows up.

Hmm, the step 4 transition actually has a set math implication, in that different resource interpretations could impact the resource owner interpretation and therefore the authorization server interpretation. My proposal sent yesterday should be enhanced with a note covering that point.

*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Fri, Dec 30, 2016 at 1:08 PM, Adrian Gropper wrote:

...

I think FHIR has more than one way to specify a resource for a single patient and this would be true of other APIs beyond healthcare. It would be incredibly helpful if UMA gave examples of the specific ways FHIR does this.

Adrian

On Fri, Dec 30, 2016 at 4:04 PM, Eve Maler wrote:

...

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 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Fri, Dec 30, 2016 at 12:57 AM, Adrian Gropper

...

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 wrote:

...

We have one more instance of wording similar to this in RReg:

In Sec 2.1 https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-02.html#res... (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 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Mon, Dec 12, 2016 at 5:30 PM, Eve Maler 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 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Thu, Dec 8, 2016 at 10:03 AM, Justin Richer 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

--

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/

-- 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/

Since I was just getting up to the point of working on an editorial instruction related to Sec 1.4.3 (Protected Resource Interface and Related Resource Server Actions), which contains the "other relevant clause" mentioned upthread, I thought I'd try out a rolled-up revision of the set math implication I just mentioned. Since this is not particularly dependent on our other set math discussions, I feel safe including this in rev 10 unless people have corrections they'd like to make to it: *"The resource server MAY register for protection a single resource that, from its perspective, has multiple parts, or has dynamic elements such as the capacity for querying or filtering, or otherwise has internal complexity. Note: The resource server alone is responsible for maintaining the necessary mappings between any such complexity (which might result, for example, in different requests coming from the client) and a single resource identifier known to the authorization server. Such complexity may also require interpretation on the resource server's part when the client makes a tokenless access attempt, in order to establish a resource identifier, and therefore resource owner and authorization server, of record before requesting permissions on the client's behalf."* *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Fri, Dec 30, 2016 at 1:47 PM, Eve Maler wrote:

These sorts of things are pretty much outside the realm of UMA's actual protection model. I'm really not sure it's practical for the generic UMA specification to provide specific API semantics/syntax guidance. At best, we could provide a non-normative description or two of what we mean by "querying or filtering" etc., probably using much more widely known and understood APIs than FHIR, or perhaps fictional APIs that illustrate common characteristics of other real ones.

More practical would be for HEART and other API protection-defining bodies to document such mappings themselves if they think it's important for API calls bearing queries for x and patient ID y to correspond.

*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Fri, Dec 30, 2016 at 1:41 PM, Adrian Gropper wrote:

...

IMHO, we'd be foolish to ignore the specific example of FHIR before we put UMA.next to bed.

Adrian

On Fri, Dec 30, 2016 at 4:28 PM, Eve Maler wrote:

...

UMA can't do this for every UMA-protected API because this is where the APIs' semantics come into play; it would behoove API publishers, especially those of public/standard/implemented-by-more-than-one-party APIs, to document this themselves.

Note that there's another clause that's relevant, from Core Sec 1.4.3 rev 09 https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-09.html#resource-serv...; see the bold part: "Any one resource that the resource server has registered for protection MAY consist, from the resource server's perspective, of multiple parts, or have dynamic elements such as the capacity for querying or filtering, or otherwise have internal complexity. It alone is responsible for maintaining the necessary mappings between these complex representations *(which might be expressed, for example, as different requests coming from the client)* and the single resource identifier known to the authorization server."

We had a version of this in UMA1, but based on experience (FHIR being one of the more complex APIs -- "there's more than one way to do it!" :-) ), we sharpened it up a lot more. (Rev 10 will change it to active voice.) The client only knows the API and what they're trying to accomplish, but don't know resource IDs. The AS only knows what resources get registered. The RS (API publisher) is the only thing that can keep tabs on the correlation, in the sense of a) what resource, b) what resource owner, and c) what authorization server to go with when the client shows up.

Hmm, the step 4 transition actually has a set math implication, in that different resource interpretations could impact the resource owner interpretation and therefore the authorization server interpretation. My proposal sent yesterday should be enhanced with a note covering that point.

*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Fri, Dec 30, 2016 at 1:08 PM, Adrian Gropper wrote:

...

I think FHIR has more than one way to specify a resource for a single patient and this would be true of other APIs beyond healthcare. It would be incredibly helpful if UMA gave examples of the specific ways FHIR does this.

Adrian

On Fri, Dec 30, 2016 at 4:04 PM, Eve Maler wrote:

...

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 <(425)%20345-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 wrote:

> We have one more instance of wording similar to this in RReg: > > In Sec 2.1 > https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-02.html#res... > (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 <(425)%20345-6756> | Skype: xmlgrrl > | Twitter: @xmlgrrl > > > > > On Mon, Dec 12, 2016 at 5:30 PM, Eve Maler 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 <(425)%20345-6756> | Skype: xmlgrrl > | Twitter: @xmlgrrl > > > > > On Thu, Dec 8, 2016 at 10:03 AM, Justin Richer > 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 > >

--

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/

--

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/