>From today’s CSM Passcode:
Photo series: What does privacy mean to you?
<http://csmonitor.us8.list-manage1.com/track/click?u=b06a12b90ba88b6eeea5d7d…>
At the South by Southwest Interactive festival, Monitor photographer Ann
Hermes asked that question. Her photo series shows that the people's
attitudes toward privacy are deeply personal. Here's what she found out:
"Privacy means fairness. How do we allow people to be treated appropriately
in terms of their digital lives, as well as their offline lives. How do we
ensure that they have access and control to their information?" *– FTC
Commissioner Julie Brill*
"Privacy is the ability to have safe spaces to associate with others and to
share controversial ideas and to explore controversial ideas – without fear
of the tyranny of the majority or the elites to prevent you from doing so." *–
Kevin Bankston, New America’s Open Technology Institute*
“As someone who comes from a background that isn’t necessarily the
mainstream – my parents were immigrants, I’m South Asian, I’m gay – there’s
all these things we have to think about our identities and what we reveal
to the world. We all construct ourselves in different ways and privacy is a
big part of that." *– G.S. Hans, Center for Democracy & Technology*
"I think the principle is bigger than the threat for me - my stuff is not
that secret, but I just don’t want it to be everywhere." *– Ville Ailio,
consultant*
*See the entire photo series here.*
<http://csmonitor.us8.list-manage.com/track/click?u=b06a12b90ba88b6eeea5d7d9…>
// Ann Hermes
<http://csmonitor.us8.list-manage.com/track/click?u=b06a12b90ba88b6eeea5d7d9…>
Sincerely,
John Wunderlich
@PrivacyCDN
Call: +1 (647) 669-4749
eMail: john(a)wunderlich.ca
--
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system. If you are not the intended recipient
you are notified that disclosing, copying, distributing or taking any
action in reliance on the contents of this information is strictly
prohibited.
Worth watching
The Death of Privacy?
http://tvo.org/video/programs/the-agenda-with-steve-paikin/the-death-of-pri…
--
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system. If you are not the intended recipient
you are notified that disclosing, copying, distributing or taking any
action in reliance on the contents of this information is strictly
prohibited.
An FYI
Warning: Math Ahead
http://repository.cmu.edu/jpc/vol7/iss1/5/
Sincerely,
John Wunderlich
@PrivacyCDN
Call: +1 (647) 669-4749
eMail: john(a)wunderlich.ca
--
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system. If you are not the intended recipient
you are notified that disclosing, copying, distributing or taking any
action in reliance on the contents of this information is strictly
prohibited.
[John W, forgive me: I unilaterally changed how the "nonfunctional
requirements" table headers read after the meeting. If we want to change
them back, great... I was just confused reading them after a few hours had
elapsed...]
http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes
2016-03-18
- External review and reviewers of our work at the Q1 mark
- Action items for the model definition editors regarding last week's
consensus definitions
- In-scope and out-of-scope trust relationships and their names (see
this thread
<https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/ia6qmjk92…>
and
below)
- Disentangling meanings of "delegation" – do we need a group norm
about terminology?
- How do we square the "Requesting Party"/Grantee/Potential Grantee
circle?
Attending: Eve, Kathleen, John W, Sal, Ann (regrets from Adrian, Mark)
*AI:* Eve, Jim: Revise our CmA model definitions with new consensus
definitions.
Eve's premise was that anything with an UMA technical artifact really has
to be in scope, and a direct relationship with any service operator with an
UMA-specific purpose for existing (namely the AS operator) seems plausible
to be in scope.
Would it be useful to write an explanatory document for reviewers about
these relationships?
Should we be naming the agreements at all? There will be multiple actual
agreements, for example, at different phases, or for whatever reason. And
(channeling Jim) there are literally different agreement/contract workflow
phases such as offer, acceptance, etc., and different sides of the equation
might be offering or whatever. And given that English is only our first
target language and not our only one, perhaps it should be a principle of
ours that we should name as few things as we can get away with, so as not
to have "language skew". Since our ultimate deliverables are at the size of
"clauses", we need not care (for purposes of discussing trust
relationships) about the larger combinatorial things into which they're
mixed. Jim has put together quite a few assembled agreements, contracts,
offers, etc., and we might do the same with our clauses as exemplars, but
in the main we expect they'll be non-normative. So we've saved the
candidate names, but kept them non-normative.
We have established to our satisfaction that there is complete separation
between the legal and technical work of UMA by demonstrating that a
technically conforming deployment of UMA services could be out of
compliance with the data protection laws of some jurisdiction. Our "Russian
example" is apt here: A Russian Grantor cannot legally allow a non-Russian
"Requesting Party" access to their own data.
The clauses need to set up the correct preconditions for a deployment of
UMA that encourages a "race to the top" in a greater alignment of
incentives among the parties and in behavior that is compliant to relevant
nonfunctional requirements (such as regulations).
John notes: "Makes me think that we need something like: Authorizing Server
Operator - Regulating Body: Allowed-To-Release"
Trust relationship
Dependencies on existing nonfunctional requirements
In scope for model text work?
(Candidate names of agreements formed out of our official clauses)
Technical artifact
Dependencies on existing technical artifacts
Discussion
Resource Subject - Grantor (if they are different) n/a No n/a n/a n/a
RSO - ASO n/a Yes Protection API client agreement OAuth client credentials
for RS n/a
Grantor - ASO n/a Yes Authorization services agreement n/a n/a This has no
technical artifact in UMA, and therefore no exact or obvious moment of
appearing "on stage" for our work. Does this have an impact on whether it
is in scope based on the rationale above? We agreed there are definitely
reasons to have UMA-specific clauses, looking at our draft ones.
Grantor - RSO RSO - ASO Yes Resource protection agreement PAT OAuth client
credentials for RS It's awkward to have a two-party agreement resting on a
PAT. There are plenty of agreements where there are multiple Persons in one
of the roles, but we're not so sure about true three-role agreements.
Client Operator - ASO n/a Yes Authorization API client agreement OAuth
client credentials for Client n/a We have not scrutinized the definition of
Client Operator. Let's put a pin in that to be sure it's okay.
"RqP" - Client Operator n/a No n/a n/a n/a We need to work on the term for
"RqP". Let's put a pin in that.
"RqP" - ASO Client Operator - ASO Yes Resource authorization agreement
AAT OAuth
client credentials for Client The same discussion about n-party agreements
above applies here.
Grantor - "RqP" Resource Subject - Grantor, RSO - ASO, Grantor - ASO,
Grantor - RSO, Client Operator - ASO, "RqP" - Client Operator, "RqP" - ASO,
Grantor - "RqP" Yes?
Resource sharing agreement
Resource access agreement
Trust elevation mechanism and specifically claims subprotocol OAuth client
credentials for RS, PAT, OAuth client credentials for Client, AAT Could be
in the form of a consent receipt, sent to a notification endpoint. Is this
trust relationship too "dependent" to be in scope, or does the calculus
work? More discussion is needed.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
Hi everyone,
There are a bunch of issues open on the UMA spec that are currently awaiting assignment to some future revision of the specification as they’d break backwards compatibility in a not-fun fashion. Instead of simply letting these languish here awaiting their time in the spotlight, we decided to go ahead and implement them all together using MITREid Connect (an UMA 1.0.1 implementation) as a base.
Changes include:
- Removal of the RPT endpoint, in favor of using the token endpoint and a new grant type (#153)
- Removal of the AAT (#154)
- Removal of extraneous bits of the resource set registration URL pattern (#155)
- Alignment of the discovery document with OIDC discovery (#157)
- Removal of “version” field in discovery document, instead document is published under new .well-known URL pattern (#159)
- Change use of “scopes” name in responses to something more explicit (#158)
- Ability of client to specify scopes in token request (#165)
- Addition of the claims-gathering URL to the need_info response, removal of “redirect_user” as redundant in this case (#167)
- Simplification of the “need_info” response structure, removal of extraneous object layers (#237)
- Rotation of ticket values on all requests to token endpoint or claims endpoint to mitigate session fixation and related attacks (#239, #205)
As noted above, these are all filed as issues with the UMA working group and all have been well documented to date. We built what we thought would be the best solution to each of these issues in turn.
We’ve implemented all of these changes in a branch in our server that we’re putting under the title “multiparty”, as in “multiparty delegation protocol”. Since this isn’t compliant with UMA (in some cases by design), these changes are not in our master branch nor in our release stream at this time. But the code is still publicly available:
https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/tree/m…
We’ve also implemented a very, very simple client and a very, very simple protected resource using the same changes above, as well as all the “best practice” recommended changes in 1.0.1 that should probably become requirements in future versions (such as returning the ticket in a header from the resource):
https://github.com/jricher/multiparty-resourcehttps://github.com/jricher/multiparty-client
You can run all three of these components together on a localhost Tomcat instance to try them out. Speaking from my own personal experience developing both this new code set and the original UMA spec, I can say that I prefer this new version hands down. The code is drastically simplified in a number of places, information flow is much cleaner overall, and there’s less guesswork expected of components at each step. The nature of some of these changes (like removal of the AAT) make this new protocol immediately more applicable to a wide ecosystem use case as well.
— Justin
http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes
2016-03-18
- External review and reviewers of our work at the Q1 mark
- Action items for the model definition editors regarding last week's
consensus definitions
- In-scope and out-of-scope trust relationships and their names (see
this thread
<https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/ia6qmjk92…>
and
below)
- Disentangling meanings of "delegation" – do we need a group norm
about terminology?
- How do we square the "Requesting Party"/Grantee/Potential Grantee
circle?
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-17
Minutes(Unofficial ad hoc meeting notes prior to call)
Attending: Eve, Sarah, Justin, Adrian, Maciej, Domenico, Andi, George, Sal
Justin suggests shortening the abstract and introduction by removing the
first sentence.
Justin suggests adding 'NOT RECOMMENDED' to the RFC2119 boilerplate that we
use. In fact, we should add an editorial issue about this so that we update
the other docs eventually, too!
We discussed future-proofing this extension so that it applies, as well, to
(e.g.) any UMA V1.0.x or UMA V1.x that might be susceptible to the same
attack. We still need normative references to V1.0 and V1.0.1 because of
the section references into specific sections of the text, and because the
attack is known to appear in those versions, but we want to broaden the
normative language in the spec to refer to "...and any other similar
versions of the UMA specification to which this attack applies, and in Sec
1.2, say something like "An UMA authorization server that would have
implemented a requesting party claims endpoint susceptible to this attack...
"
To make the extension spec more helpful, we want to have subsections inside
the main Sec 2: Introduction, explaining who should be using this
enhancement and why; Attack Sequence, a shortened version of what's in the
non-normative doc; and Mitigation, the normative part of the spec.
Maciej noted that "use this endpoint exclusively for interacting with the
end-user requesting party to gather claims". Justin thought that breaking
out each bullet as a full sentence with a single instruction: "The AS MUST
do this..." "The AS MUST do that..." etc. would be good. Specifically,
we're thinking that talking about something like "replacing any use of the
original claims endpoint with the enhanced claims endpoint would help, vs.
"exclusively" language.
Let's also change this: "Effectively, when this extension is in effect, the
requirement stated in Section 3.2.2 of UMA1.0.1 as "Permission tickets MUST
NOT be single-use" is nullfied" to this: "Effectively, this extension
supersedes the requirements stated in Section 3.2.2 of [UMA101]
<file:///Users/eve/Documents/wg-uma/draft-uma-claims-sec-ext-v1_0.html#UMA101>
as
"Permission tickets MUST NOT be single-use" and Section 3.6.3 as "The same
permission ticket value that the client provided in the request.""
*Discussion of the new mitigation idea:* Eve's idea is that by combining
trust elevation mechanisms (through policy conditions that require their
combination – recalling that policy is OOB wrt UMA) in significant order,
thereby "binding" Bob across those mechanisms/endpoints, trust in the
legitimate RqP can be correctly elevated and the attacker can be tossed.
Roll call
Quorum was reached. (Huge showing today!)
Approve minutes
Approve minutes of UMA telecon 2016-03-10
<http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-10>:
NO OBJECTIONS!!!
Issue 239 materials
*Report out and final conclusions if all goes well:* We walked through the
ad hoc discussion above.
We discussed whether we should name the "parallel endpoint" some sort of
"forever and all" name that will last through the next big UMA version
overhaul, whenever that might be. Currently we've suggested
security_enhanced_claims_endpoint. Let's indeed put this out on the list to
think about it, with conclusions by next week. John likes
secure_random_value_claims_endpoint. Let's continue discussing.
We forgot to record that we want to delete "This extension does not change
any original requirements of UMA if used without these enhancements."
Justin recommends adding "unguessable" to "securely random"; agreed. In
that case, we should consider doing this in the original spec too, as an
editorial change vs. "The permission ticket is a short-lived correlation
handle generated by the authorization server that is intended to be opaque
to resource servers and clients. The authorization server therefore MUST
ensure that the ticket is securely random, much as it would for
authorization codes and access tokens. Within these constraints, however,
the authorization server MAY format the ticket however it chooses, for
example either as a random string that references data held on the server
or by including data within the ticket itself."; let's add this as an issue.
Finally: typo: s/ot permissions/of permissions/
Justin points out that order wouldn't be significant because if Bob is
strongly bound initially, then Eve has no chance already. But it's not a
particularly interesting mitigation from his perspective unless it's the
combination of, say, "I'm 'Bob' to some strength (authentication_context)
plus 'I'm a doctor' (specific claim requirements) and 'this client has no
knowledge of/ability to/trustworthiness to provide my doctor claim (
redirect_user is required)". E.g.: Bob gets his authentication through a
hospital, but Alice has a carveout against his access to her information.
Her policy is: If is_doctor and is_not 'Bob', then the logic would want to
grab the current identity in a convenient way. John notes: "We call Alice’s
carveout a “Lockbox” in Ontario. She can lock access to her records to some
or all people or groups (barring ‘break the glass’)."
Eve discovered that there are two implementations so far, Gluu and FR, that
do use the AAT ("session") for meeting policy conditions, so that's at
least a data point for discussing this mitigation. This particular
combination hasn't been deployed, however.
So what should be done about this mitigation? It falls into a gray area.
It's not something that belongs in a normative spec. It's not for us to
"accept" or "reject". We need to qualify who is susceptible to the attack
by adding the word "solely", and ensuring that readers of the spec
understand that even if they mitigate the attack in any other way, it's
"tricksy". We will simply refer them to the background document for "background
information on this attack, the provided mitigation, and other discussion.",
and then provide discussion of this additional mitigation idea for those
who wish to pursue it. We're not going to spend lots of energy writing a
full description of the "combined trust elevation mitigation" in that
background doc.
We should also add something to the UIG pointing to the new spec and doc,
so people won't miss them.
*AI:* Eve and Maciej: Revise the extension spec for final consideration
next week.
*AI:* Eve: Revise the background doc for next week.
*AI:* (somebody, can it please not be Eve? [image: (smile)] ): Add a
mention of the attack and mitigation to the UIG.
"Why UMA?" AI report and discussion
Domenico ran through his analysis of business audiences and ways to make
the case. Eve described new discussions in the UMA Dev group around
appealing to the developer audience, and invited UMA WGers to contribute.
New concrete case studies are extremely welcome, along with statements from
individuals and organizations involved in them in their own words; these
are the most powerful.
Attendees
As of 18 Feb 2016, quorum is 6 of 11. (François, Domenico, Kathleen, Sal,
Thomas, Andi, Robert, Maciej, Eve, Mike, Sarah)
1. Domenico
2. Sal
3. Andi
4. Kathleen
5. Sal
6. Robert
7. Maciej
8. Eve
9. Mike
10. Sarah
Non-voting participants:
- Justin
- Adrian
- George
- Ishan
- Scott
- John
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
<—cut from list posting
The Usable Privacy Policy project has just released a new website that
features over 20,000 policy annotations collected for nearly 200 website
privacy policies. This is just the beginning of an effort, where we hope to
further scale this process with machine learning and natural processing
technologies. The website is at: explore.usableprivacy.org. You may also be
interested in the joint CMU-Fordham press release<
http://www.cs.cmu.edu/news/new-website-sheds-light-privacy-policy-shortcomi…>
about the site or a recent article in Consumerist<
https://consumerist.com/2016/03/11/researchers-launch-tool-to-help-show-you…
>.
Moving forward, we plan to issue a small number of updates each year
(perhaps 2 or 3) about our progress and opportunities for members of
different communities to use our results and/or also contribute to our
effort. If you would like to be removed from this mailing list, please
follow the instructions at:
https://lists.andrew.cmu.edu/mailman/listinfo/usable-policies
—->
Sincerely,
John Wunderlich
@PrivacyCDN
Call: +1 (647) 669-4749
eMail: john(a)wunderlich.ca
--
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system. If you are not the intended recipient
you are notified that disclosing, copying, distributing or taking any
action in reliance on the contents of this information is strictly
prohibited.
