October 2015 - WG-UMA - mailman.kantarainitiative.org

Re: [WG-UMA] [projectvrm] Consent Receipts: Safe Harbour through Personal Data Control
by Adrian Gropper 23 Oct '15

23 Oct '15

Apologies for continuing this valuable cross-posting. Notice, first and foremost, requires a destination address. This address can be either: - arbitrarily specified by the subject of the PII (the principal) - specified by the vendor or service provider - chosen, NASCAR-style, from a list of well-known intermediaries - sent to a public ledger like a blockchain Where do we work out which of these meets our intent and drives adoption? Adrian On Fri, Oct 23, 2015 at 8:11 AM, Mark Lizar <info(a)smartspecies.com> wrote: > Some background on the thinking that has gone into the design of a consent > receipt specific to safe harbour. > > One of the biggest issues with moving data across jurisdictions is the > different laws. This is in addition to the complexity of difference > cultures and different contexts that create expectations of data use. This > is why data protection and privacy in the context of cross border data > transfers is so difficult. > > A preferred way to expedite data transfers is for people to control their > own data and to consent to its access, rather than only its transfer. (A > new and developing layer of technical capability affectionately called > Consent 2.0) > > A consent receipt is like a reverse (VRM) cookie, its a record that people > get to track organisations and what they share about them. It collects the > identity attributes that are provided, the purpose they are provided for > and who they are shared with. The Consent Receipt can also carry > assurances, trust marks, security promises and even reputations. > > Combined with UMA, a consent receipt is a tool to show how personal > control over data means that it can stay in a jurisdiction, and be shared > with others. In essence people can control access to data and create their > own safe harbour to transfer data across borders. > > Regardless of who the data controller is, a key benefit of a consent > receipt for organisations is the ability to add, record and provide > jurisdictionally based notice requirements to a consent notice. > Demonstrating compliance (or not) by the notices provided with the privacy > policy for sharing and data use. Combined with model contract clauses, > which are used to assure liability and define data controls, consent > receipts address Privacy Policies while model contracts address Terms of > Use policies. > > In the EU, notice and consent is required for all personal data collection > and sharing. In the US, explicit notices are required for consent for > sensitive data. Data covered by federal laws like COPPA, GBLA, HIPPA, and > the like. > > In every jurisdiction sensitive data comes with specific, legally defined, > notice requirements, that are localised. All sensitive personal data > transfer requires explicit consent and notice that are intended to assure > informed consent. It is for this reason that a consent receipt has been > designed to highlight sensitive data, both what an individual considers > sensitive and what the law considers sensitive, so that PII can be shared. > > If an organisation doesn’t meet legal notice requirements across > jurisdictions, then it doesn’t matter what model contract clauses are used, > the consent is not informed and compliant for sensitive data collection and > sharing. In fact, model clauses can become a source of toxic liability and > can be used to hold the data controller or processors liable. (which builds > trust) > > Posted on consentreceipt.org > <http://consentreceipt.org/consent-receipts-safe-harbour-through-personal-da…> > > -- 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/

1 0

Consent Receipts: Safe Harbour through Personal Data Control
by Mark Lizar 23 Oct '15

23 Oct '15

Some background on the thinking that has gone into the design of a consent receipt specific to safe harbour. One of the biggest issues with moving data across jurisdictions is the different laws. This is in addition to the complexity of difference cultures and different contexts that create expectations of data use. This is why data protection and privacy in the context of cross border data transfers is so difficult. A preferred way to expedite data transfers is for people to control their own data and to consent to its access, rather than only its transfer. (A new and developing layer of technical capability affectionately called Consent 2.0) A consent receipt is like a reverse (VRM) cookie, its a record that people get to track organisations and what they share about them. It collects the identity attributes that are provided, the purpose they are provided for and who they are shared with. The Consent Receipt can also carry assurances, trust marks, security promises and even reputations. Combined with UMA, a consent receipt is a tool to show how personal control over data means that it can stay in a jurisdiction, and be shared with others. In essence people can control access to data and create their own safe harbour to transfer data across borders. Regardless of who the data controller is, a key benefit of a consent receipt for organisations is the ability to add, record and provide jurisdictionally based notice requirements to a consent notice. Demonstrating compliance (or not) by the notices provided with the privacy policy for sharing and data use. Combined with model contract clauses, which are used to assure liability and define data controls, consent receipts address Privacy Policies while model contracts address Terms of Use policies. In the EU, notice and consent is required for all personal data collection and sharing. In the US, explicit notices are required for consent for sensitive data. Data covered by federal laws like COPPA, GBLA, HIPPA, and the like. In every jurisdiction sensitive data comes with specific, legally defined, notice requirements, that are localised. All sensitive personal data transfer requires explicit consent and notice that are intended to assure informed consent. It is for this reason that a consent receipt has been designed to highlight sensitive data, both what an individual considers sensitive and what the law considers sensitive, so that PII can be shared. If an organisation doesn’t meet legal notice requirements across jurisdictions, then it doesn’t matter what model contract clauses are used, the consent is not informed and compliant for sensitive data collection and sharing. In fact, model clauses can become a source of toxic liability and can be used to hold the data controller or processors liable. (which builds trust) Posted on consentreceipt.org <http://consentreceipt.org/consent-receipts-safe-harbour-through-personal-da…>

2 2

Reminder: UMA legal subgroup telecon 2015-10-23
by Eve Maler 23 Oct '15

23 Oct '15

No time or energy for a formal agenda template tonight, but as noted in an earlier thread, one thing I'd like to do is analyze Binding Obs as a source of UMA-specific model clauses we can use for our various top-level goals. I'll try to have my act together further by tomorrow. :-) Eve (from my iPad)

1 0

Collaborate on UMA Projects at the FutureCommerce Hackathon
by Dazza Greenwood 22 Oct '15

22 Oct '15

Hi all - Please join us at the FutureCommerce hackathon and symposium this November 20-22 and join or propose a project to hack something creative for/with UMA! Register at: FutureCommerce.CIVICS.com The event will primarily be online (offering options for individual online participants and virtual teams) and includes an in-person social learning track hosted the MIT Media Lab and Cambridge Innovation Center on Friday, November 20th. ** UMA Opportunities ** * Jim Hazard will be leading FutureCommerce sessions focused on integrating personal data contract clauses into standard "trust frameworks" using CommonAccord in a way that is consistent with the general discussion of the UMA-Legal subgroup. Don't miss the chance to learn and contribute to that important work! * I will be recruiting participants and kicking-off a session to explore and brainstorm ideas and options for design and prototyping Adrian Gropper's innovating idea to develop a free reference implementation of a general-purpose personal authorization server. This is a great project in general and especially valuable for UMA adoption. And it features clear, initial requirements for Business, Legal and Technical dimensions of the system - making it easier for the FutureCommercce participants from Massachusetts Legal Hackers to collaborate with the team on this project. See Adrian's recent email on this topic (forwarded directly below) for more information on the idea and how to get involved generally to create the reference implementation. * If you have an idea for an UMA or related project or other session, let me know or just propose it in the coming weeks when participants have an opportunity to begin forming teams and projects. I'll ensure there is a tag and other ways to filter and see all the UMA related activities in one easy view. * If you want to work on these or other UMA related projects or topics at the FutureCommerce event, in the please mention UMA in the registration form section describing your interests so I can get an advance count and ensure appropriate space and other resources for online and in-person participants. Hope to see you at the event and don't hesitate to reach out directly with any questions ideas or other feedback! Cheers, - Dazza _ _ _ _ _ _ _ _ _ _ _ _ _ _ | Dazza Greenwood, JD | CIVICS.com, Founder & Principal | MIT Media Lab, Visiting Scientist | Vmail: 617.500.3644 | Email: dazza(a)CIVICS.com | Biz: http://CIVICS.com | MIT: https://law.MIT.edu | Me: DazzaGreenwood.com | Twitter: @DazzaGreenwood | Google+: google.com/+DazzaGreenwood | LinkedIn: linkedin.com/in/DazzaGreenwood | GitHub: github.com/DazzaGreenwood/Interface | Postal: P.O. Box 425845 Cambridge, MA 02142 | _ _ _ _ _ _ _ _ _ _ _ _ _ _ On Wed, Oct 21, 2015 at 2:40 PM, Adrian Gropper <agropper(a)healthurl.com> wrote: > I'm resuming this thread after a bunch of side conversations in this UMA > thread and the [Legal] thread here > <http://kantarainitiative.org/pipermail/wg-uma/2015-October/003907.html>. > The main goal of the WAS thread is: > > To promote UMA adoption by giving away a reference implementation of a > general-purpose personal authorization server. The idea is to reduce both > the risk and the complexity of any UMA implementation by encouraging both > RS and C, in whatever industries they happen to be, to demonstrate > compatibility with the generic and unmodified WAS reference implementation. > > *BLT observations are*: > > - The B is a non-commercial open source community of folks interested > in promoting UMA by distributing a useful piece of code in the form of an > UMA Authorization Server that could be used by any individual if the RS > allows a user-specified AS. The B reasons for why an RS would want to allow > a user-specified AS are out of scope but suggestions are most welcome. In > general, a user-specified AS is most useful in use-cases where governance > and jurisdiction are a barrier to interoperability and a customer-centric > approach can bypass this problem. I suggested blockchain (Bitcoin adoption) > as an example of business adopting a federation and jurisdiction-free > approach based on individual sovereignty. An open source useful piece of > code can succeed by creating secondary business opportunities. > > > - The L is a simple-minded approach that keeps all of the legal and > business constraints entirely under the RS control. A personal open source > authorization server like WAS does not introduce a new party into the > equation. From the RS and C legal perspective, the WAS is equivalent to the > customer's Web browser. The idea here is to short-circuit extensive legal > analysis by simply translating the RS's current release of information > contracts into an UMA-compatible format. In some domains, this legal "safe > harbor" is actually regulated as a "customer right of access". > > > - The T is to deliver a virtual machine that any individual can run > (hosted or unhosted) with growing functionality over time. As Eve puts it: > "The AS is available as-a-service (that is, doesn’t frequently get shut > down), speaks standard UMA, handles the more “dynamic” patterns (such as > being able to hand out client credentials readily to OAuth clients it > hasn’t met before)..." Eve goes on to say: "... and is acceptable to other > entities/parties on a business/legal level and vice versa (whatever those > constraints and concerns might be)". To this last point, I refer back to > the simple-minded legal approach above where we avoid introducing any new > actors to the WAS party. > > > *What are the gaps between UMA 1.0.1 and a WAS reference implementation? * > > These seem to fall into two categories related to (a) identity and access > to identity attributes of the requesting party, and (b) vocabulary issues > specific to an industry or domain that would prevent a generic and person > centered reference imlementation. > > (a) * Identity*: > The RqP may not agree to present claims to any random and untrusted AS and > the RS may need verified attributes about the RqP in order to meet legal or > business mandates. As Eve puts it: "If you think of an AS as an RP/claims > client, then the RqP might be worried that the AS is going to be exposed to > the RqP’s PII, and the RqP might be worried about the AS’s capacity to keep > that data safe etc. This falls into the category of good security and > privacy practice, nothing UMA-specific. It may also fall into the category > of regulated care of PII" > > A generic WAS could present the RO with one or more of these four options > for registering clients and issuing authorization tokens: > > - AS issues local credentials (password, SSH, FIDO) - this is the > trivial minimum. > - AS accepts RqP authentication by the RS - this is no worse than the > pre-UMA situation and it presents no new legal or business risk to the RS. > - AS accepts a federated authentication, including blind credential > brokers that protect the RqPs attributes from both the AS and the RS. > - AS accepts public claims via a blockchain mechanism like OneName > https://onename.com/ > > Note that none of these are domain specific and at least one allows the RS > to take responsibility for Bob and seal the interop deal. > > According to Eve, the Client needs to know what claims are of interest and > this could be specific to the RS and the domain. I hope UMA can keep this a > matter between the RS and C as much as possible but I agree that really > sophisticated policy calculus by the AS would turn into a vocabulary > interop problem. > > (b) *Vocabulary*: > > (b) The AS currently needs extensions to compute on domain-specific > vocabulary. Neither the RS nor the AS should be forced to accept executable > code from anywhere. I see one or more of the following options: > > > - The resource registration process has no domain-specific vocabulary > (e.g.: release 1 BTC to the C from this account, or release the PDF > document associated with this resource), allow read but not write, etc... > > > - The RS sends a blank HTML form to the AS with whatever scopes and > scope descriptions it chooses along with contract boilerplate and links to > published terms of use and privacy policies. The form is typically a public > document and may be a standard. > > > 1. The RO fills in the form and stores it at the AS > 2. The blank form is available to the RqP via the RS or the AS > 3. The RqP makes a request via the form and presents claims > 4. The AS issues a permission token based on the stored form and may > also respond to simple introspection requests as defined by the form > 5. The RS manages the transaction and sends a receipt with the > applicable scopes back to the AS > > About this, Eve says: "Here this is some putative UMA that doesn’t exist, > I’m afraid. Resource set descriptions currently get registered by the RS at > the AS independently of any particular RqP/client. What gets registered is: > Resource X with possible scopes y and z is now under your protection. Alice > can then go to the AS and create policies that map “subjects” (actually > some mix of client/requesting party descriptors) to resource sets and > specific scopes, like this: "Dr. Bob (using client ccc?) can get access to > resource X with scope y (perhaps up until time limit T) (perhaps only if > strongly authentication in manner A) (etc.)." This enables the AS to know > what precise claim descriptors etc. to ask for when Dr. Bob and his client > approach seeking access. If they match the descriptors, then what gets put > in the client’s token is a permission block saying: “(This subject — it’s > actually implicit from the token’s bearer in the current profile) can get > access to resource X with scope y (perhaps and this permission expires at > time limit T) (etc.)." > > Clearly, a generic WAS, incapable of computing on domain vocabulary would > not be able to offer this kind of control to the RO. It would need to trust > the RS to offer a limited menu of options that the RO would pick from at > resource registration time. Any negotiation or complexity in requesting > claims would need to occur between the RS and the RqP/C directly and the AS > would simply be notified of the outcome as with a Consent Receipt. > > In summary, I propose that UMA adoption would be well served by an > approach that avoids any change in the Business or Legal practice of the > Resource Server (by not introducing any new parties or federations) and > facilitates the Technical conversion to UMA by providing a Free generic and > personal authorization server for both RS and C to test against. > > Another perspective on this action item is available here: > http://kantarainitiative.org/pipermail/wg-uma/2015-October/003907.html > > Here's a websequencediagram > <http://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgQmFzZWxpbmUgSEV…> > that illustrates WAS that I created for the HEART discussion: > > title Baseline HEART Sequence Diagram > > participant "Alice resource\nowner (RO)" as RO > participant "NPE resource\nserver (RS)" as RS > participant "Agent authorization\nserver (AS)" as AS > participant "Bob client\napp (C)" as C > participant "Bob requesting\nparty (RqP)" as RqP > note over RO, RS, AS, C, RqP > NPE = Non-Person Entity / This is the Individual-to-Individual Design > Pattern > end note > > > RO->RS: Presents In Person > RS->RO: Gets Credential > RO->RS: Sign In to NPE Portal > RS->RO: Display NPE ROI Form > RO->RS: Specify Auth'z Server (AS) > RO->RS: Text Resource Description > RO->AS: Sign In to Agent Portal > > RS->AS: FHIR Resource Description > AS->RO: Text Resource Description > RO->AS: Confirm Authorization Policies > AS->RS: Confirm\nResource Registration > RS->AS: Consent Receipt > > note over RO, RS, AS > End of UMA Phase 1 > end note > > note over RS, AS, C, RqP > RqP discovers the resource via message or directory query > end note > > RqP->AS: Presents Claims\ne.g. bob(a)medicalsociety.org > AS->RqP: Gets Credential > RqP->AS: Sign In to AS > RqP->AS: May need to Register Client > AS->C: Consent Receipt > C->AS: Requests Authorization > AS->C: Grants Authorization > > note over RS, AS, C, RqP > End of UMA Phase 2 > end note > > C->RS: Access FHIR Resource > RS->AS: Accounting for Disclosure > > note over RS, AS, C, RqP > End of UMA Phase 3 > end note > > -- Adrian > ______________________________________________________ > ______________________________________________________ > > > > > > > > On Sat, Oct 17, 2015 at 12:14 AM, BridgeIDentity <tim(a)bridgeidentity.com> > wrote: > >> I see the errors of complexity again. >> >> If you live in a box world, you must look like a box even if you want to >> be and feel you are a circle. >> >> The block chain architecture allows a more user centric platform moving >> forward and with less complexity. >> >> I am not sure how you will unravel this and how you can take valuable >> components and apply them in a resourceful manner. >> >> UMA I believe does not truly address the transformation of many to one to >> one to many data in a cultural transition. >> >> Blockchain allows for this architecture to begin, and for that reason “I >> am Out”. >> >> >> >> Tim >> >> >> >> *From:* wg-uma-bounces(a)kantarainitiative.org [mailto: >> wg-uma-bounces(a)kantarainitiative.org] *On Behalf Of *Dazza Greenwood >> *Sent:* Friday, October 16, 2015 2:43 PM >> *To:* Adrian Gropper >> *Cc:* wg-uma(a)kantarainitiative.org WG >> *Subject:* Re: [WG-UMA] A Wallet Authorization Server >> >> >> >> Where is the BLT sandwich? That really is the question. >> >> >> >> Are there any parties you know of who are using UMA for some/any business >> purpose today (ie not for testing or because they "have to" for some >> reason) and who might be interested in this? If so, we'd have a reasonable >> starting basis to discuss potential business and legal arrangements that >> may be acceptable to the parties. Best of all, by starting with actual >> parties it is possible to check back with them later to test whether the >> ideas are or are not likely to be acceptable in practice... by arranging a >> demo, pilot or other explore and then asking them. >> >> >> >> I want a BLT sandwich as much as anybody, but am unaware of any way to >> establish business and legal acceptability without knowing realistic >> information about the parties, their transactions and the context of their >> relationships with one another. If you don't have business and legal >> parties (as in parties who are in fact using or exploring business use of >> the system) then you really can only test a T sandwich and make educated >> guesses about the B and the L. So, your BLT sandwich is with parties who >> do or are actively considering using UMA for their regular business >> purposes and can be involved in some type of user testing or other feedback >> cycle. >> >> >> >> The B comes first because it is the meat. If you only have T and even L >> and T, you should be asking: Where's the Beef? >> >> >> _ _ _ _ _ _ _ _ _ _ _ _ _ _ >> | Dazza Greenwood, JD >> | CIVICS.com, Founder & Principal >> | MIT Media Lab, Visiting Scientist >> | Vmail: 617.500.3644 >> | Email: dazza(a)CIVICS.com >> | Biz: http://CIVICS.com >> | MIT: https://law.MIT.edu >> | Me: DazzaGreenwood.com >> | Twitter: @DazzaGreenwood >> | Google+: google.com/+DazzaGreenwood >> | LinkedIn: linkedin.com/in/DazzaGreenwood >> | GitHub: github.com/DazzaGreenwood/Interface >> | Postal: P.O. Box 425845 Cambridge, MA 02142 >> | _ _ _ _ _ _ _ _ _ _ _ _ _ _ >> >> >> >> On Fri, Oct 16, 2015 at 10:35 AM, Adrian Gropper <agropper(a)healthurl.com> >> wrote: >> >> - Available as a service: could be satisfied with a $5/mo VM and a >> https://letsencrypt.org/ cert? >> - Speaks standard UMA: can WAS be a profile on UMA 1.0.1 or does it >> need UMA 2.0? >> - Dynamic client registration: ROs can choose their app (store) >> whitelists - what has this to do with UMA? >> - *Acceptable to other entities/parties at the business and legal >> level: what can UMA do to help this?* >> >> That last one is the key to UMA adoption. If the legal and business >> barrier is low then adoption might follow the Bitcoin / blockchain model >> where adoption is driven by a combination of branded centralized services >> and pure p2p energy. CommonAccord and emerging blockchain inspired >> governance models will also help reduce the legal and business barrier. >> >> Where's my BLT sandwich? >> >> Adrian >> >> >> >> On Thu, Oct 15, 2015 at 9:31 PM, Eve Maler <eve(a)xmlgrrl.com> wrote: >> >> As long as the AS is available as-a-service (that is, doesn’t frequently >> get shut down), speaks standard UMA, handles the more “dynamic” patterns >> (such as being able to hand out client credentials readily to OAuth clients >> it hasn’t met before), and is acceptable to other entities/parties on a >> business/legal level and vice versa (whatever those constraints and >> concerns might be), I’m not sure what other compatibility concerns there >> are. >> >> >> >> Eve >> >> >> >> On 15 Oct 2015, at 1:19 PM, Adrian Gropper <agropper(a)healthurl.com> >> wrote: >> >> >> >> Imagine the authorization server as an on-line wallet: secure, compatible >> regardless of jurisdiction, and owned. It would share a lot of the >> attributes and business issues of Bitcoin wallets. For lack of a more >> inspired name, I will call it a Wallet Authorization Server or WAS. >> >> Like Bitcoin wallets, the WAS will be delivered to individuals as either >> a VM they can run on hardware / VMs they control or not. Individuals will >> choose sovereignty vs. convenience. >> >> Do we want to drive future versions of UMA in this direction? If so, what >> are the minimum essential components of the WAS in order to make it >> compatible with all UMA resource servers and all clients that are willing >> to support a truly user-centric model? >> >> >> >> Adrian >> >> _______________________________________________ >> WG-UMA mailing list >> WG-UMA(a)kantarainitiative.org >> http://kantarainitiative.org/mailman/listinfo/wg-uma >> >> >> >> >> Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | >> Calendar: xmlgrrl(a)gmail.com >> >> >> >> >> >> >> -- >> >> >> >> 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/ >> >> >> _______________________________________________ >> WG-UMA mailing list >> WG-UMA(a)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/ > > _______________________________________________ > WG-UMA mailing list > WG-UMA(a)kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/wg-uma > >

1 0

Sorry for the late notice: CANCELING today's meeting
by Eve Maler 22 Oct '15

22 Oct '15

I'm not feeling well today. Eve (from my iPad)

2 2

A Wallet Authorization Server
by Adrian Gropper 21 Oct '15

21 Oct '15

Imagine the authorization server as an on-line wallet: secure, compatible regardless of jurisdiction, and owned. It would share a lot of the attributes and business issues of Bitcoin wallets. For lack of a more inspired name, I will call it a Wallet Authorization Server or WAS. Like Bitcoin wallets, the WAS will be delivered to individuals as either a VM they can run on hardware / VMs they control or not. Individuals will choose sovereignty vs. convenience. Do we want to drive future versions of UMA in this direction? If so, what are the minimum essential components of the WAS in order to make it compatible with all UMA resource servers and all clients that are willing to support a truly user-centric model? Adrian <http://patientprivacyrights.org/donate-2/>

4 10

Agenda for UMA telecon 2015-10-22
by Eve Maler 20 Oct '15

20 Oct '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-10-22 Date and Time Thu Oct 22, 9-10am PT Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540# Screen sharing: http://join.me/findthomas <http://join.me/findthomas> - NOTE: IGNORE the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar <http://kantarainitiative.org/confluence/display/uma/Calendar> Agenda Public Review status and outstanding comment review Considering our Independent Submission stance of record: is there news? Permission registration extension spec idea How are we doing on other outstanding AIs? If time: Consider charter revisions/cleanup AOB Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Re: [WG-UMA] A Wallet Authorization Server
by Eve Maler 19 Oct '15

19 Oct '15

Thanks for the reminder and the code, Phil! I know of plans to convene sessions on "UMA developer resources” and interop, and we typically hold an “UMA 101” session (which, in deference to Justin, we will have to call “the 101 on UMA 1.0.1”, or perhaps “the 411 on 1.0.1” or something). Oh, and I’ve also signed up to do one of the speed demos, showing what I’ve been calling V2 of my UMA demo built on the OpenUMA project. Eve > On 19 Oct 2015, at 9:55 AM, Phillip J. Windley Ph.D. <windley(a)gmail.com> wrote: > > If you’re not already signed up for IIW next week, use this code to get 25% off and come talk about this in person: > > https://iiwxxi-21.eventbrite.com/?discount=UMA_IIX_XXI_25 <https://iiwxxi-21.eventbrite.com/?discount=UMA_IIX_XXI_25> > > This is the kind of conversation we need at IIW. > >> On Oct 19, 2015, at 10:14 AM, Eve Maler <eve(a)xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote: >> >> Some food for thought... >> >> I suspect reasonable people can disagree on what the complex parts are and what the simple parts are, depending on what parts of a system they are responsible for. >> >> There has been a robust conversation in IIWs past about the proposition of a server that would be totally controlled by the individual. Adrian convened a very interesting session at IIW 20 that resulted in these notes <http://iiw.idcommons.net/My_OWN_$5/mo_UMA_Authorization_Server>, called “My OWN $5/mo UMA Authorization Server”. It would be cool to do this again and see how far we’ve come. It’s been very tough to get “user-centric identity/access servers” going as a real-life attractive proposition, but it could still happen at some point. >> >> I had an ongoing conversation with Steve Greenberg* this weekend, who pointed out a curious phenomenon: In the world of identity, we’ve had the “T” for a very long time, but we’ve sometimes struggled with the “B”, and the “L” situation is pretty immature. (Which is why I glommed on to Tim Reiniger when I first met him — he had a lot to do with authoring the Virginia digital identity law!) But in the world of consent and trust and so on, it’s really about agency — and we’ve actually had the “B” and “L” elements for a long time; the “T” element is the new guy at the table. [He wants me to call him “Steve Greenberg, noted raconteur and bon vivant” :-) ] >> >> OAuth (6749 and 6750 together) is about 96 pages on my printer. OIDC Core all by itself, ignoring the other important specs, is 93. UMA Core is 34 and RSR is 23. At least by the metric of the technical complexity that it adds on top of the other pieces, I’m not sure UMA’s “T" is all that complex. >> >> As for “where the beef is”, in my own world I have several examples of business model <https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Business-Models> #1 (easy) coming up, and, increasingly, some instances of business model #2 (medium). Business model #3 — Adrian’s goal — is the hardest. The reason we have a legal subgroup at all is to accelerate comfort with/reduce inhibitors to deploying the harder cases. The WG’s work is generally “(B)T” at this point, and the legal subgroup is generally “BL”. >> >> Looking at the provided diagram, I’m not sure I understand the blockchain connection, as UMA is, by design, identity-ignostic and you can get pretty far without having to use “the same identity” in many UMA-related contexts (e.g., an RO can use a different identity at each RS and the AS and — when acting as an RqP — at each client, and authorization can be based on non-uniquely identifying factors of an RqP through “claims-based access control”). Would love to understand this better. >> >> FWIW… >> >> Eve >> >>> On 16 Oct 2015, at 6:20 PM, Adrian Gropper <agropper(a)healthurl.com <mailto:agropper@healthurl.com>> wrote: >>> >>> On Fri, Oct 16, 2015 at 3:43 PM, Dazza Greenwood <dazza(a)civics.com <mailto:dazza@civics.com>> wrote: >>> The B comes first because it is the meat. If you only have T and even L and T, you should be asking: Where's the Beef? >>> >>> I should know better than to argue with a lawyer, in public, but I can't resist... >>> >>> UMA is already too complicated for its own good. I've been in a position to work on UMA-related things as much as anyone from the B perspective except probably Eve. The legal subgroup discussions are thrilling, but they are not headed in the direction of reducing UMA's complexity. CommonAccord and consent receipts will be huge contributions to UMA but we need to consider the UMA adoption model as a whole. >>> >>> UMA's path to success lies in packaging the LT goodies with the simplest possible B by giving away a fully functional personal Authorization Server. This will provide the essential reference implementation at the root of any new standard. It's unreasonable to expect anything as complex as UMA to take off when people have to digest OAuth, OpenID Connect, federation, servers, scopes, clients, and agency before a single transaction takes place. >>> >>> The B I'm proposing is a non-profit community chartered to promote UMA to individuals as a component of both decentralized and corporate services. The L and T can include CommonAccord and MVCR and any other technology that will reduce the barrier to UMA for RS and C developers. >>> >>> Adrian >>> >>> >>> On Fri, Oct 16, 2015 at 10:35 AM, Adrian Gropper <agropper(a)healthurl.com <mailto:agropper@healthurl.com>> wrote: >>> Available as a service: could be satisfied with a $5/mo VM and a https://letsencrypt.org/ <https://letsencrypt.org/> cert? >>> Speaks standard UMA: can WAS be a profile on UMA 1.0.1 or does it need UMA 2.0? >>> Dynamic client registration: ROs can choose their app (store) whitelists - what has this to do with UMA? >>> Acceptable to other entities/parties at the business and legal level: what can UMA do to help this? >>> That last one is the key to UMA adoption. If the legal and business barrier is low then adoption might follow the Bitcoin / blockchain model where adoption is driven by a combination of branded centralized services and pure p2p energy. CommonAccord and emerging blockchain inspired governance models will also help reduce the legal and business barrier. >>> >>> Where's my BLT sandwich? >>> >>> Adrian >>> >>> >>> On Thu, Oct 15, 2015 at 9:31 PM, Eve Maler <eve(a)xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote: >>> As long as the AS is available as-a-service (that is, doesn’t frequently get shut down), speaks standard UMA, handles the more “dynamic” patterns (such as being able to hand out client credentials readily to OAuth clients it hasn’t met before), and is acceptable to other entities/parties on a business/legal level and vice versa (whatever those constraints and concerns might be), I’m not sure what other compatibility concerns there are. >>> >>> Eve >>> >>>> On 15 Oct 2015, at 1:19 PM, Adrian Gropper <agropper(a)healthurl.com <mailto:agropper@healthurl.com>> wrote: >>>> >>>> Imagine the authorization server as an on-line wallet: secure, compatible regardless of jurisdiction, and owned. It would share a lot of the attributes and business issues of Bitcoin wallets. For lack of a more inspired name, I will call it a Wallet Authorization Server or WAS. >>>> >>>> Like Bitcoin wallets, the WAS will be delivered to individuals as either a VM they can run on hardware / VMs they control or not. Individuals will choose sovereignty vs. convenience. >>>> >>>> Do we want to drive future versions of UMA in this direction? If so, what are the minimum essential components of the WAS in order to make it compatible with all UMA resource servers and all clients that are willing to support a truly user-centric model? >>>> >>>> Adrian <http://patientprivacyrights.org/donate-2/> >> >> >> Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com <mailto:xmlgrrl@gmail.com> >> >> _______________________________________________ >> WG-UMA mailing list >> WG-UMA(a)kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> >> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma> Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

If I didn't mention this already: new Intro to UMA page
by Eve Maler 19 Oct '15

19 Oct '15

http://kantarainitiative.org/confluence/display/uma/Introduction+to+UMA Let me know what you think. And feel free to add (or suggest) items. Thanks! Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

3 3

Notes from UMA legal subgroup telecon 2015-10-16
by Eve Maler 17 Oct '15

17 Oct '15

Fri Oct 16 8-9am PT Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540# Screen sharing: http://join.me/findthomas <http://join.me/findthomas> - NOTE: IGNORE the join.me <http://join.me/> dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar <http://kantarainitiative.org/confluence/display/uma/Calendar> Report from the APAC-friendly UMA sync discussion <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/1vA-frUlo…> Take a look at the latest CommonAccord artifacts and progress What are the appropriate next steps and timeline? What artifacts will give concrete assistance to UMA deployers in 2015? Anything worth retaining/saving from Binding Obs? Should we sunset it? Attending: Eve, Steve, Ann, Domenico, Andrew, Jon, Tom, Dazza, Jim, Adrian, Tim, Paul, David David Maisenberg is a nonpracticing attorney who works with startups and law firms - "UMA is the solution" to many things he’s working on. In discussing some of the challenges of multi-AS environments that are specific to access control propositions (e.g., might Alice want to control whether the RqP is allowed to share her resource further? might the answer want to turn on which AS the RqP has chosen?), Adrian points out that this is related to 42CFR Part 2 regulations. This relates to substance abuse/mental health data. You can ask a patient to consent generically to release; you have to list explicitly who will see it, and come back to the patient if you want to share it beyond that circle. And data must be tagged with that specific type of sensitivity, and be redacted to the point of obscuring whether it ever existed if it wasn’t consented to be shared. What if Alice were in jurisdiction A and Bob were in jurisdiction B? CommonAccord could handle multi-jurisdiction challenges. We would try to cover as much of the jurisdictional differences as we can ahead of time, but it may be an 80/20 approach. “Lawyers are there for error correction” — could be before or after the fact. Text could be tweaked as further deltas are identified. Could the rule set text call out to the relevant laws/rules by reference? “These rules are subject to the laws of the state of MD” or whatever. There are limits to this approach. What would be productive to work on: UMA-specific model text, non-specific text, both? Could be both. If we could throw together some candidate “stacks” (the “legal stack” and “technology stack” concepts of CommonAccord) and try them out, that would be valuable. Jim’s candidate UMA text was just thrown together — don’t take it too seriously! Model forms would also be hugely useful. GA4GH has a lot of similar problems. Finally, at a granular level, what would the layers of consents, resource exchange, etc. be? This sounds like it’s about “semantic interop”. Jim sez: it’s “technical emojis”. :-) Each community of interest might have different sets of these. So, three tasks: stacks, clauses, semantics. For the stack task, how does the CommonAccord logic work regarding flowing through to different jurisdictions? It appears that once you’ve designed and tested these flows, they can be captured and reused. And you can scope the results, so that (e.g.) the French guys can work on an outline independently when it’s specific to them. For the clauses task, how do you ensure that (e.g.) the French and English versions mean the same thing? This is metaphysical and cultural. The experts in that field end up having to make a judgment. In Germany, the shape of a consent may be different from in the US. (Eve points to this book <https://en.wikipedia.org/wiki/Le_Ton_beau_de_Marot>!) For the stack and clauses tasks, are these anticipated to be pairwise, and if so, do we simply focus on the 3-4 pairwise “liability tensions” (meta-use cases) that have been identified as being of most interest so far? RO-RqP: for example, purpose-of-use or other constraints on further downstream use (as discussed in this chain-link confidentiality paper <http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2045818>); and our question about the relevance of licensing comes up here (IP/real property rights) RS-AS: traditionally, services have done authorization jobs themselves and now we’re talking about their outsourcing this; they might have security/privacy requirements RO-AS: would the resource owner feel comfortable trusting, say, a “social” AS to do this job correctly? AS-(OAuth client): we do have some example agreement text <https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Examples-of-Ter…> for this in the social IdP realm Jim suggests looking at existing examples and starting from there. Jon asks: How pairwise or non-pairwise are these, really? Delving into the distinction between “informed consent” and “authorization” and statutory use, in US healthcare regulations, there are implications regarding whether you have to do Accounting for Disclosures. There are perhaps interesting distinctions between different ways of deploying UMA-enabled applications when it comes to whether something counts as “consented” sharing. If your app (RS) provides a “share” button, is that consent? If your app (RS) hooks up to an AS that has a “share” button? If your AS supports a “pending requests approval” flow? If your app (RS) and client and AS collaborate to simulate a typical OAuth flow that is guaranteed to let you “uncheck scopes”? Next steps: AI: Steve, Dazza: Research “meaning of consent” and UMA usage patterns for next week. AI: Eve: Share links with Steve/Dazza to help in their task. AI: Jim: Help the rest of us understand how to “build stacks” — a tutorial. Dazza has announced the FutureCommerce Legal Hackathon! Should there be an UMA track? He’ll send out a link about this! Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

2 2