{"action":"created","issue":{"url":"https://api.github.com/repos/xmlgrrl/UMA-Specifications/issues/124","labels_url":"https://api.github.com/repos/xmlgrrl/UMA-Specifications/issues/124/labels{/name}","comments_url":"https://api.github.com/repos/xmlgrrl/UMA-Specifications/issues/124/comments","events_url":"https://api.github.com/repos/xmlgrrl/UMA-Specifications/issues/124/events","html_url":"https://github.com/xmlgrrl/UMA-Specifications/issues/124","id":53359729,"number":124,"title":"Sharpen the extensibility profiles","user":{"login":"xmlgrrl","id":248613,"avatar_url":"https://avatars.githubusercontent.com/u/248613?v=3","gravatar_id":"","url":"https://api.github.com/users/xmlgrrl","html_url":"https://github.com/xmlgrrl","followers_url":"https://api.github.com/users/xmlgrrl/followers","following_url":"https://api.github.com/users/xmlgrrl/following{/other_user}","gists_url":"https://api.github.com/users/xmlgrrl/gists{/gist_id}","starred_url":"https://api.github.com/users/xmlgrrl/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/xmlgrrl/subscriptions","organizations_url":"https://api.github.com/users/xmlgrrl/orgs","repos_url":"https://api.github.com/users/xmlgrrl/repos","events_url":"https://api.github.com/users/xmlgrrl/events{/privacy}","received_events_url":"https://api.github.com/users/xmlgrrl/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/xmlgrrl/UMA-Specifications/labels/core","name":"core","color":"0b02e1"}],"state":"open","locked":false,"assignee":null,"milestone":{"url":"https://api.github.com/repos/xmlgrrl/UMA-Specifications/milestones/1","labels_url":"https://api.github.com/repos/xmlgrrl/UMA-Specifications/milestones/1/labels","id":731015,"number":1,"title":"V1.0 Public Review prep","description":"Need to dispose of V0.9 Public Review comments and an appropriate set (decided by the WG) of other issues by a quorate UMA WG all-hands meeting on (or electronic WG ballot started around) January 23, 2015. This will enable a V1.0 Public Review, LC Draft Recommendation electronic ballot, and Kantara All-Member Ballot to complete in the RSA Conference timeframe (April 20-24, 2015).","creator":{"login":"xmlgrrl","id":248613,"avatar_url":"https://avatars.githubusercontent.com/u/248613?v=3","gravatar_id":"","url":"https://api.github.com/users/xmlgrrl","html_url":"https://github.com/xmlgrrl","followers_url":"https://api.github.com/users/xmlgrrl/followers","following_url":"https://api.github.com/users/xmlgrrl/following{/other_user}","gists_url":"https://api.github.com/users/xmlgrrl/gists{/gist_id}","starred_url":"https://api.github.com/users/xmlgrrl/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/xmlgrrl/subscriptions","organizations_url":"https://api.github.com/users/xmlgrrl/orgs","repos_url":"https://api.github.com/users/xmlgrrl/repos","events_url":"https://api.github.com/users/xmlgrrl/events{/privacy}","received_events_url":"https://api.github.com/users/xmlgrrl/received_events","type":"User","site_admin":false},"open_issues":6,"closed_issues":21,"state":"open","created_at":"2014-07-24T15:46:33Z","updated_at":"2015-01-05T02:57:58Z","due_on":"2015-01-23T08:00:00Z","closed_at":null},"comments":3,"created_at":"2015-01-05T02:57:58Z","updated_at":"2015-01-05T04:43:02Z","closed_at":null,"body":"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...\r\n\r\n====\r\n\r\nThis 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:\r\n\r\n\t• Identifying URI: https://docs.kantarainitiative.org/uma/profiles/prot-ext-1.0\r\n\t• Profile author and contact information: Mark Dobrinic (mdobrinic@cozmanova.com)\r\n\t• Updates or obsoletes: None; this profile is new.\r\n\t• Security considerations: See below.\r\n\t• Privacy considerations: See below.\r\n\t• Error states: See below.\r\n\r\nUsing 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:\r\n\r\n\t• [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)\r\n\t• Resource set registration or configuration\r\n\t• Registration or configuration of requested permissions\r\n\t• RPT introspection or examination\r\n\t• Error state generation and reporting at any level\r\n\r\nInteractions 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.\r\n\r\nAn 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).\r\n\r\nSame-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.\r\n\r\nSame-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."},"comment":{"url":"https://api.github.com/repos/xmlgrrl/UMA-Specifications/issues/comments/68667913","html_url":"https://github.com/xmlgrrl/UMA-Specifications/issues/124#issuecomment-68667913","issue_url":"https://api.github.com/repos/xmlgrrl/UMA-Specifications/issues/124","id":68667913,"user":{"login":"agropper","id":138849,"avatar_url":"https://avatars.githubusercontent.com/u/138849?v=3","gravatar_id":"","url":"https://api.github.com/users/agropper","html_url":"https://github.com/agropper","followers_url":"https://api.github.com/users/agropper/followers","following_url":"https://api.github.com/users/agropper/following{/other_user}","gists_url":"https://api.github.com/users/agropper/gists{/gist_id}","starred_url":"https://api.github.com/users/agropper/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/agropper/subscriptions","organizations_url":"https://api.github.com/users/agropper/orgs","repos_url":"https://api.github.com/users/agropper/repos","events_url":"https://api.github.com/users/agropper/events{/privacy}","received_events_url":"https://api.github.com/users/agropper/received_events","type":"User","site_admin":false},"created_at":"2015-01-05T04:43:02Z","updated_at":"2015-01-05T04:43:02Z","body":"I'm not worried about auth within a legal liability domain.\r\n\r\nI'm terrified about b2b data brokers and private networks between separate\r\nlegal entities. Anything we do that allows for these dark networks to\r\ncontinue will marginalize UMA to the b2c ghetto with only a fraction of the\r\nresources online that are accessible over the dark network.\r\n\r\nSimply put, we encourage the RS to register all private information (even\r\nde-identified individual data) that can be shared as an UMA resource with\r\nsome standard UMA AS. That way, only policy stands in the way of scaling\r\nUMA to 21st century interop. If we do that, accountability and compliance\r\nwill drive UMA adoption. If we don't, competition with the dark networks\r\nwill limit the network effect for UMA adoption.\r\n\r\nAdrian\r\n\r\nOn Sun, Jan 4, 2015 at 11:34 PM, Eve Maler <notifications@github.com> wrote:\r\n\r\n> Most (all?) patient-centric health data ecosystems are loosely coupled and\r\n> will tend to require the separation baked into the default UMA AS/RS/client\r\n> design, but we've been finding that quite a few deployment ecosystems are\r\n> narrow in focus, where some of the entities are run exclusively by the same\r\n> company. In these cases, it makes no sense to force them to go through HTTP\r\n> when it’s the same hunk of software communicating with itself, while there\r\n> are still benefits to using UMA in the rest of the orbit. This is why we\r\n> invented the extensibility profiling mechanism: to scope down the amount of\r\n> security/privacy/interop \"monkey business” an entity can get away with in\r\n> one sphere, while forcing it to act properly in all the other spheres.\r\n>\r\n> You can see one analogous example in federated identity systems, when\r\n> federation is used internally in companies to achieve SSO inside their\r\n> “four walls” when the company owns multiple web properties. E.g., you use\r\n> an amazon.com login to get into Amazon Fresh, Amazon Prime, etc.\r\n> Naturally, Amazon has visibility into both the IdP and all the SPs.\r\n>\r\n> Another thought: The new wording I proposed gives the example of IoT\r\n> protocols (CoAP and DTLS). This profiling mechanism is also a mechanism for\r\n> binding the UMA protocol to different underlying non-HTTP transports, while\r\n> keeping it as loosely coupled as it is now. That may be something we want\r\n> to mention explicitly, since it's a rationale that's not about tight\r\n> coupling but about non-HTTP binding.\r\n>\r\n> —\r\n> Reply to this email directly or view it on GitHub\r\n> <https://github.com/xmlgrrl/UMA-Specifications/issues/124#issuecomment-68667542>\r\n> .\r\n>\r\n\r\n\r\n\r\n-- \r\nAdrian Gropper MD\r\nEnsure Health Information Privacy. Support Patient Privacy Rights.\r\n*http://patientprivacyrights.org/donate-2/*\r\n<http://patientprivacyrights.org/donate-2/>"}}