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 1
Thanks 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 2
The 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.
Adrian
On Sun, Jan 8, 2017 at 2:24 AM Eve Maler