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