Note that we have the "shoebox endpoint" (aka notification endpoint) on our 2016 roadmap, associated with several use case buckets, and now seems as good a time as any to bring it up!

(I don't believe that the CISWG has a protocol/API element on its current docket. If we were to start doing something like this, we should coordinate with that WG to ensure cohesiveness going forward.)

Indeed, whatever AS the RO is using might not be the home of her preferred endpoint for such notifications, for a variety of reasons. In fact, I still think that an email address or other type of communications endpoint (vs. an API endpoint) could be preferable for a lot of people at this point.

I could see UMA defining an optional capability in the discovery document for an AS to advertise an RO's chosen notification endpoint to the RS, with a way to indicate what standard formats the endpoint accepts. (What format of notification would an RS be sending regarding exceptions to RO wishes?)

In the case where the AS hosted an endpoint itself, btw, if it were to create consent receipts, I'm assuming it wouldn't literally send receipts through HTTP to its own endpoint.

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

On Thu, Jun 2, 2016 at 2:46 PM, Adrian Gropper <agropper@healthurl.com> wrote:

This is why UMA is incomplete without the ability for the RO to register a transaction receipt endpoint. When all is said and done, as Eve describes, the only thing that keeps the system accountable and that provides the 'good fath' notice capability that makes agency law practical is the registration of a notification endpoint at UMA resource registration time.

It seems foolish to me to leave this notification out of the spec. The question then becomes: Should the notification endpoint be at the AS or independent?

In my world, where the AS is specified by the RO, the answer is obvious and it brings the benefit that a 'good faith' override by the RS might trigger a change in AS policy for the next transaction.

In a case where the AS is not legally and effectively specified by the RO, there's good reason for the RO to want to specify a notification endpoint that they do control. This then means the RO needs to interact with the AS out-of-band in reaction to whatever the RS just did to them.

Adrian

On Thursday, June 2, 2016, Eve Maler <eve@xmlgrrl.com> wrote:
John W asked in Skype whether deterministic sets, as we were just talking about in the call today, would allow for overrides of a policy for purposes of data localization or regulation etc. My response was that it's an AS that represents the results of the RO's policy in a token, and it's an RS that might override those results once the client brings that token over to the RS (the "Adrian clause").

Thus, I wondered if the RS's actual granted access should be considered a sixth set of a scopes that we should track, describe, etc. in the spec. It would probably be useful in the UMA Legal work, at a minimum!

I also noted that the RS might need to do overrides in an out-of-band-of-UMA situation. As we've discussed in the past, such a situation might include court order or a "break glass" situation. This would mean that this set of scopes could be interestingly disjoint from the original five sets.

Thoughts?

(BTW, I've sent out Slack invitations, as we'd promised, to everyone who currently gets Google Calendar invitations to our WG meetings, plus whoever else asked for an invitation. If you'd like to get an invitation in addition, drop me a private note.)

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

--

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/