agropper
commented
9 years ago This sounds like a privacy disaster. As soon as we open the possibility for resource servers to avoid a public and standardized API we create a loophole to avoid person-managed consent that you can drive an aircraft carrier through. The whole point of UMA from my perspective is to give a person-managed AS a fair shot at RS APIs.
This compromise in privacy is an existential threat to what we're trying to do.
Adrian
On Sun, Jan 4, 2015 at 9:57 PM, Eve Maler notifications@github.com wrote:
Roland has suggested that we get the extensibility profiles out of the business of describing what the two entities would do in interacting, and instead spend more time talking about the relevant security and privacy considerations. I wrote up a sample attempt based on our discussion. He'd still like to see the embedded list of interaction opportunities go away. Let's discuss...
This section defines a profile for UMA where the authorization server and resource server roles either reside in the same system entity or otherwise have a privileged communications channel between them. Following is a summary:
• Identifying URI: https://docs.kantarainitiative.org/uma/profiles/prot-ext-1.0 • Profile author and contact information: Mark Dobrinic (mdobrinic@cozmanova.com) • Updates or obsoletes: None; this profile is new. • Security considerations: See below. • Privacy considerations: See below. • Error states: See below.
Using this profile, the resource server MAY use means other than the HTTP-based protection API that is protected by TLS and OAuth (or an OAuth-based authentication protocol) to communicate with the authorization server in all respects, including using software interfaces and methods rather than network interfaces and APIs. The following list of interaction opportunities is a non-exhaustive sample:
• [the list would change per profile -- I've softened it and taken out all the MAYs] The mechanism of PAT issuance (though issuance is still REQUIRED) • Resource set registration or configuration • Registration or configuration of requested permissions • RPT introspection or examination • Error state generation and reporting at any level
Interactions with entities other than the authorization server or resource server MUST be preserved exactly as they would have if either of them were standalone, unless other extensibility profiles are also in use.
An authorization server using any of the opportunities afforded by this profile MUST declare use of this profile by supplying its identifying URI for one of its "uma_profiles_supported" values in its configuration data (see Section 1.4).
Same-entity communication or a tight integration of entities has the opportunity to make deployments more secure by reducing possible attack vectors. However, if the entities do not use TLS but communicate across a transport layer, it is RECOMMENDED to use an alternate means of transport-layer security, for example, using DTLS in the case of a Constrained Application Protocol (CoAP)-based UMA profile.
Same-entity communication or a tight integration of entities has the potential to compromise privacy by promoting the freer exchange of personal information within a deployment ecosystem. It is RECOMMENDED to account for privacy impacts in each deployment scenario.
— Reply to this email directly or view it on GitHub https://github.com/xmlgrrl/UMA-Specifications/issues/124.
Adrian Gropper MD Ensure Health Information Privacy. Support Patient Privacy Rights. http://patientprivacyrights.org/donate-2/ http://patientprivacyrights.org/donate-2/
xmlgrrl
rohe
Roland has suggested that we get the extensibility profiles out of the business of describing what the two entities would do in interacting, and instead spend more time talking about the relevant security and privacy considerations. I wrote up a sample attempt based on our discussion. He'd still like to see the embedded list of interaction opportunities go away. Let's discuss...
This section defines a profile for UMA where the authorization server and resource server roles either reside in the same system entity or otherwise have a privileged communications channel between them. Following is a summary:
Using this profile, the resource server MAY use means other than the HTTP-based protection API that is protected by TLS and OAuth (or an OAuth-based authentication protocol) to communicate with the authorization server in all respects, including using software interfaces and methods rather than network interfaces and APIs. The following list of interaction opportunities is a non-exhaustive sample:
Interactions with entities other than the authorization server or resource server MUST be preserved exactly as they would have if either of them were standalone, unless other extensibility profiles are also in use.
An authorization server using any of the opportunities afforded by this profile MUST declare use of this profile by supplying its identifying URI for one of its "uma_profiles_supported" values in its configuration data (see Section 1.4).
Same-entity communication or a tight integration of entities has the opportunity to make deployments more secure by reducing possible attack vectors. However, if the entities do not use TLS but communicate across a transport layer, it is RECOMMENDED to use an alternate means of transport-layer security, for example, using DTLS in the case of a Constrained Application Protocol (CoAP)-based UMA profile.
Same-entity communication or a tight integration of entities has the potential to compromise privacy by promoting the freer exchange of personal information within a deployment ecosystem. It is RECOMMENDED to account for privacy impacts in each deployment scenario.