I'm not sure what you mean by separable. Based on 5+ years of experience with access to health records, if we do not specify enough of the Resource Registration Contract to have a legal contract then the value and adoption of UMA will be severely harmed. Resource Registration is a legal contract between the RS and the AS.If any aspect of a legal contract is not in the standard, then each hospital or other resource server makes the process of registering a resource just different enough to make the process impractical at scale. This is exactly what we have with API access in healthcare today. Even though there are laws and standards, usability from the patient experience perspective is awful and app developers have to go to intermediary data brokers that add cost and mostly don't exist.AdrianOn Tue, Jan 17, 2017 at 6:41 PM, Eve Maler <eve@xmlgrrl.com> wrote:Yeah, I'm not sure that #2 is very outside the RS's responsibility as part of its AS/RO relationship anyway, since it's a question of what it does in response to getting the token the client brought it that was issued by the AS. It's all of a piece.Other questions are: If an RO wants their own contact point of record not to be at the AS (say, at a totally different service, or to give an email or something), should that be okay? What should count as an endpoint?And since this sounds increasingly orthogonal to UMA, could we literally make it separable and loosely coupled?On Tue, Jan 17, 2017 at 3:21 PM, Adrian Gropper <agropper@healthurl.com> wrote:I might agree with your definitions. As far as I'm concerned, 1. has to do with an AS-RS contract. 2. Has to do with the RS-Client interaction. You could say that the AS-RS contract should also deal with RS-Client issues via the same endpoint and I'd be hard-pressed to argue. This two or one endpoint is more a standards issue than I know how to deal with.Adrian--On Tue, Jan 17, 2017 at 6:11 PM, Eve Maler <eve@xmlgrrl.com> wrote:I think I hear you say (to boil some things down a lot, maybe too much) that:
- The RS-AS relationship in the RO context needs an address where notifications should be sent. This could be a "traditional" API endpoint, or the RO could identify a ledger mechanism if they want.
- There are other notifications the RS needs to send as a result of other actions not strictly inside the RS-AS box, but due to other similar obligations, and those need an endpoint or mechanism too.
On Sun, Jan 8, 2017 at 3:41 AM, Adrian Gropper <agropper@healthurl.com> wrote:I propose we discuss the potential for two separate shoebox endpoints in order to avoid lengthy syntax standardization work. We might call them call them Shoebox for Phase. 1 and Shoebox for Phase.2.Shoebox for Phase 1Thanks for assembling the history, and apologies in advance if this in the legal notes, but here is a rationale for UMA's "differential interest":Resource registration is a contract between two parties (RS and AS). Pretty much every contract I've ever seen has, near the end, a clause that gives the address where notices are to be sent for each party. Consider this contract in the GDPR 'data controller' sense, where the RS wants to claim they're merely the 'data operator' to shield themselves from added liability as 'data controller'.If UMA does not provide native support for this notice aspect of a contract, then resource control delegation contracts would need to be an extension of UMA and conversely, UMA resource registration contracts could not simply be logged by the AS and RS for compliance reasons. UMA's differential interest is to drive adoption of UMA by playing a clear and essential role in this GDPR sense.With respect to the 'blockchain' bullet, there are already multiple commercial blockchain timestamping services as well as an open service proposal, and they are being standardized. Timestamping is a more general concept than receipt storage, centralized or not. Once UMA treats standard blockchain timestamping as the commodity it is obviously becoming, then the issue of where transaction receipts are stored becomes moot: Both the RS and AS have an incentive to store the timestamped contracts and timestamped transaction receipts in order to meet compliance requirements. UMA would not be "working on centralized places to store notifications/records" because the distributed public ledger is effectively all that's needed.These two points together argue for looking at the shoebox issue _at least_ as essential for UMA Phase 1 (resource reg). Further refinement such as standardization of the syntax of the notifications as discussed in a few of the issues, is a nice-to-have but the compliance perspective I'm proposing here does not need this syntactic refinement since compliance assessment does not strictly need to be machine-processed.Shoebox for Phase 2The second reason for a shoebox endpoint relates to UMA Phase 2. As discussed under #246, https://github.com/KantaraInitiative/wg-uma/issues/246 and #245, some applications of UMA will require notice and interaction between the RS to the RO once the Client is known. This is a different use of the shoebox than the compliance reason mentioned above. To avoid a lengthy standardization discussion around this RO confirmation of RS notice we could define a separate Phase 2 shoebox endpoint where an unstructured warning could be sent to the AS. This warning could include a link back to the RS for confirmation. That link would typically force the RO to authenticate to the RS (the way they did in Phase 1) and complete the client registration process or not.AdrianOn Sun, Jan 8, 2017 at 2:24 AM Eve Maler <eve@xmlgrrl.com> wrote:______________________________We've collected a series of issues at the nexus of #trust, #ROctrl ("RO can meaningfully throttle access that RS gives"), and #ROctrl ("RS can throttle access beyond AS-imposed limits"), and "consent and notice and information sharing matters" that we have nicknamed shoebox thanks to Andrew Hughes. Here are the relevant issues; you can see some of them go way back in time!
- 246: Endpoint for collection of "receipts" and notifications of RS action in case of extraordinary behavior
- 245: Location Constraints
- 224: RS Notifies AS or RO of Access
- 63: Audit logs to support legal enforceability
- 24: Possible to audit host's compliance in giving access based on a legitimate active permission from the AM?
These issues variously detail use cases in the UMA context. This mega-issue is connected to various other efforts, including our own UMA Legal subgroup (see particularly these notes), the Consent and Information Sharing WG's Consent Receipt work (note that the CR spec has just gone out for Public Review on Jan 6), FHIR (for its "Consent" structure), and possibly others.Consent records and transaction records and signed notifications of exceptions, etc., are usually conceived of as being useful to store in a secure transaction repository of some kind. Some questions:
- Given that UMA isn't alone in this, should we even be talking about UMA-specific functionality? Are we talking about an AS hosting a "shoebox endpoint" because an AS is the right place for such a thing to be hosted, or because a server that happens to be an AS is also a "shoebox endpoint server" (or something like that)? What is UMA's differential interest? Has anyone in other groups proposed something concrete around a "shoebox endpoint"?
- There are people working on putting consent/transaction receipts on blockchains. ("Drink!") Should we be working on centralized places to store notifications/records?
- UMA Legal has figured out what it wants to do, to a point, in the legally enforceable world. How machine-readable can the proposition get -- at least for our purposes in UMA2?
Please feel free to add your own questions (or answers)..._________________
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/