I think I hear you say (to boil some things down a lot, maybe too much) that: 1. 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. 2. 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. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Sun, Jan 8, 2017 at 3:41 AM, Adrian Gropper 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 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 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 https://github.com/KantaraInitiative/wg-uma/issues/246: Endpoint for collection of "receipts" and notifications of RS action in case of extraordinary behavior - 245 https://github.com/KantaraInitiative/wg-uma/issues/245: Location Constraints - 224 https://github.com/KantaraInitiative/wg-uma/issues/224: RS Notifies AS or RO of Access - 63 https://github.com/KantaraInitiative/wg-uma/issues/63: Audit logs to support legal enforceability - 24 https://github.com/KantaraInitiative/wg-uma/issues/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 http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+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)...

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

_______________________________________________

WG-UMA mailing list

WG-UMA@kantarainitiative.org

http://kantarainitiative.org/mailman/listinfo/wg-uma

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? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Tue, Jan 17, 2017 at 3:21 PM, Adrian Gropper 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 wrote:

...

I think I hear you say (to boil some things down a lot, maybe too much) that:

1. 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. 2. 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.

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

On Sun, Jan 8, 2017 at 3:41 AM, Adrian Gropper 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 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/Kanta raInitiative/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 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 https://github.com/KantaraInitiative/wg-uma/issues/246: Endpoint for collection of "receipts" and notifications of RS action in case of extraordinary behavior - 245 https://github.com/KantaraInitiative/wg-uma/issues/245: Location Constraints - 224 https://github.com/KantaraInitiative/wg-uma/issues/224: RS Notifies AS or RO of Access - 63 https://github.com/KantaraInitiative/wg-uma/issues/63: Audit logs to support legal enforceability - 24 https://github.com/KantaraInitiative/wg-uma/issues/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 http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+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)...

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

_______________________________________________

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/

What I mean is that we should be sensitive to modularity in standardization. If the handling of contact points for contracts (thinking of the RS-AS relationship in the RO context) is something that every service provider needs anyway, then UMA maybe shouldn't be solving this all by its lonesome. OAuth has somehow lived without this, even though it's got a huge and flourishing ecosystem of third-party client applications that could probably use such a mechanism. Every API and every "contractor" dealing with humans could probably benefit from such a contact endpoint. As for sending notifications specifically about exception cases around access (given or not given) by the RS, I guess it really would be a special case vs. the above. That is, it would be a concrete, auditable technical action I (as an RO) would want an RS to take in order to live up to what would otherwise be a squishy Ts & Cs promise. The AS is a logical place to send it because the AS is authoritative for the token contents. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Tue, Jan 17, 2017 at 4:29 PM, Adrian Gropper wrote:

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.

Adrian

On Tue, Jan 17, 2017 at 6:41 PM, Eve Maler 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?

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

On Tue, Jan 17, 2017 at 3:21 PM, Adrian Gropper 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 wrote:

...

I think I hear you say (to boil some things down a lot, maybe too much) that:

1. 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. 2. 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.

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

On Sun, Jan 8, 2017 at 3:41 AM, Adrian Gropper 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 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/Kanta raInitiative/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 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 https://github.com/KantaraInitiative/wg-uma/issues/246: Endpoint for collection of "receipts" and notifications of RS action in case of extraordinary behavior - 245 https://github.com/KantaraInitiative/wg-uma/issues/245: Location Constraints - 224 https://github.com/KantaraInitiative/wg-uma/issues/224: RS Notifies AS or RO of Access - 63 https://github.com/KantaraInitiative/wg-uma/issues/63: Audit logs to support legal enforceability - 24 https://github.com/KantaraInitiative/wg-uma/issues/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 http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+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)...

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

_______________________________________________

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/