You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PrivacyCDN opened this issue
Feb 5, 2016
· 2 comments
Labels
extensionIdea that may be suitable for an extension spec or UMA Request For EnhancementRSctrlRelated to enabling the RS to exert/retain control over resource accessshoeboxRelated to consent/personal data receipt API ideastrustBusiness-legal-technical (BLT) trust
This issue came to mind in the course of a discussion around issue 239 in the workgroup call of 2016/02/04, but is unrelated to that issue. The simple use case would be where a resource owner is a citizen of a country that has data localization regulations that bar the collection, use or disclosure of citizen data in all or some other countries. For example, European data controllers may not transfer European citizens' data to countries that have not been approved for such transfers.
If Bob is the Resource Owner and he wants to grant access to his personal information, stored on a Resource Server in his own country, to a Requesting Party (Alice) located in another country, the Authorizing Server may be required to deny access because Alice is in a country that is not approved to collect personally identifiable information from Bob's country, irrespective of Bob's expressed consent.
Another case might be where a medical researcher wants to share health data with a colleague in another location. Is this disclosure allowed by the medical researcher's institution and does the researcher have to seek consent from the patient in advance of the disclosure?
Factors to consider:
Is the type of resource such that location constraints may apply (i.e. is it personally identifiable information)
The location of the Resource Server
Physical location in the case of government regulations - what constraints apply to cross border data transfers
Logical location in the case of policies related to scope - what constraints apply to data transfers within entities (Local), within federations (medium scope), or just generally.
The location of the Requesting Party - Is the requesting party in a physical or logical location that places constraints granting access.
The text was updated successfully, but these errors were encountered:
xmlgrrl
added
RSctrl
Related to enabling the RS to exert/retain control over resource access
trust
Business-legal-technical (BLT) trust
V2.0
shoebox
Related to consent/personal data receipt API ideas
labels
Jan 4, 2017
extensionIdea that may be suitable for an extension spec or UMA Request For EnhancementRSctrlRelated to enabling the RS to exert/retain control over resource accessshoeboxRelated to consent/personal data receipt API ideastrustBusiness-legal-technical (BLT) trust
Potential Location Contraints
This issue came to mind in the course of a discussion around issue 239 in the workgroup call of 2016/02/04, but is unrelated to that issue. The simple use case would be where a resource owner is a citizen of a country that has data localization regulations that bar the collection, use or disclosure of citizen data in all or some other countries. For example, European data controllers may not transfer European citizens' data to countries that have not been approved for such transfers.
If Bob is the Resource Owner and he wants to grant access to his personal information, stored on a Resource Server in his own country, to a Requesting Party (Alice) located in another country, the Authorizing Server may be required to deny access because Alice is in a country that is not approved to collect personally identifiable information from Bob's country, irrespective of Bob's expressed consent.
Another case might be where a medical researcher wants to share health data with a colleague in another location. Is this disclosure allowed by the medical researcher's institution and does the researcher have to seek consent from the patient in advance of the disclosure?
Factors to consider:
The text was updated successfully, but these errors were encountered: