- WG-UMA - mailman.kantarainitiative.org

Draft of permission registration extension spec
by Eve Maler 29 Oct '15

29 Oct '15

This is sort of an “editor’s draft”. Thanks to Roland et al. for early feedback! Does the group want to consider this ready enough for discussion as a group work product? In which case I can put it in GitHub etc… Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

You're invited: tweet chat on #ConsentFutures
by Eve Maler 25 Oct '15

25 Oct '15

Hi folks— As noted in the legal subgroup minutes already: Please join my upcoming Twitter chat Tue Nov 3 9am PT <https://www.forgerock.com/blog/twitter-chat-with-xmlgrrl-eve-maler-consentf…>! The hashtag is #ConsentFutures. The full title is Safe Harbor and the Future of Consent. I think I just discovered that our listed times are slightly incorrect because “summertime skew” will be over by Nov 3, so the UK time should be 5pm and the CET time should be 6pm. I’m sorry for any inconvenience! Please spread the word… If you let me know you’re attending, I’ll give you a shoutout in Twitter. Thanks! Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

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

23 Oct '15

John, I think we're talking past each other. You're talking about the content, and I'm talking about the context. A stable consent receipt ecosystem will evolve from the desire of both customers and vendors to engage in somewhat durable relationships. The Wired article <http://www.wired.co.uk/magazine/archive/2015/11/features/inside-facebook-me…> about Facebook Messenger gets this. Relationships and business imperatives will drive the receipt content standard. Adrian On Fri, Oct 23, 2015 at 12:38 PM, John Wunderlich <john(a)wunderlich.ca> wrote: > Adrian; > > Isn't it the case that notice requires a recipient. The actual address to > which this is delivered can be transient, anonymous, or permanent. From my > point of view the consent receipt will deliver a record of what information > was collected, by whom, and for what purposes. The presence of a GUID on > the receipt means that the transaction can be both anonymous and verifiable > after the fact - if both parties keep a copy of the receipt. And it is > certainly the case that the consent receipt format can be used to deliver a > notice - i.e. "Here is the receipt you will get if you register with our > site. Should we proceed, or should we delete your information and end the > transaction?" > > So to your question about where to work this out, I would suggest that > there is no normative or canonical answer to this question. If and when the > notion of a receipt for the collection of personal information becomes > normalized, then there will be many contextual choices. Hopefully most of > them will meet the spec we are building - but that spec has to do with the > information IN the receipt, not how it is transmitted. > > Adoption will be driven by the ability of providers to use the API we are > devloping in multiple contexts, to meet their own and their customers needs > - while providing evidence to regulators where needed. > > > Sincerely, > John Wunderlich > @PrivacyCDN > > Call: +1 (647) 669-4749 > eMail: john(a)wunderlich.ca > > On 23 October 2015 at 10:07, Adrian Gropper <agropper(a)healthurl.com> > wrote: > >> 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/ >> > > > > 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. > -- 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

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

23 Oct '15

Attending: Eve, Adrian, Ann, Andrew H, Jeff, Mark, Tim, Jim, Domenico, Dazza Regrets: Jon, Steve Mark L’s very interesting new blog post <http://consentreceipt.org/blog/> is a positive innovation-centric view of consent and what may come after the “easy path” is denied to organizations. On that note, please join Eve’s Twitter chat Tue Nov 3 9am PT <https://www.forgerock.com/blog/twitter-chat-with-xmlgrrl-eve-maler-consentf…>! The hashtag is #ConsentFutures. Two tasks we can do today: Jim’s “stack dance” and a walkthrough of Binding Obs to get inspired about UMA-specific model clauses. Andrew H is working on a project right now that involves something very much like Binding Obs. They’re currently calling them “commitments”. Some RS’s are independently operated, and they’re trying to persuade them, partly through contracts, to play ball. The technical layer is easy: “Follow the spec.” But at the business program level, they have to care, and at the legal contract level, it’s obviously relevant. (B&L are the challenge, not T.) Adrian points to this Wired article <http://www.wired.co.uk/magazine/archive/2015/11/features/inside-facebook-me…> about FB Messenger having a leg up over other apps/platforms because of its identity footprint. He sees UMA having an opportunity to provide an alternative. Eve wonders if this is relevant to his point about making the RS more comfortable with the UMA proposition by enabling RqP authentication (and maybe even claims-gathering?) through the RS. This is additionally to letting the RS continue to vet the RqP. Andrew thinks some of these could work on a B level and will provide feedback. Regarding who logs in to whom, this is a government sector project, and there are certain cultural identity practices, resulting in unique tensions and also degrees of trust. Andrew’s new term for trust frameworks is “faith frameworks”. :-) This reminds Eve of Prof. Munindar Singh’s work on “sociotechnical systems”, where “commitments is the formal name for what we’ve called obligations. Here are the references we previously shared with the WG: Readings sent by Prof. Munindar Singh: [Basic: if you have time for one paper] Norms as a Basis for Governing Sociotechnical Systems <http://www.csc.ncsu.edu/faculty/mpsingh/papers/mas/IJCAI-15-TIST.pdf>. This is a five-page extended abstract of a longer journal article. [Computational mapping to data stores; short but somewhat technical] Cupid: Commitments in Relational Algebra <http://www.csc.ncsu.edu/faculty/mpsingh/papers/mas/AAAI-15-Cupid.pdf>. [More on the conception of commitments; easy read] Commitments in Multiagent Systems: Some History, Some Confusions, Some Controversies, Some Prospects <http://www.csc.ncsu.edu/faculty/mpsingh/papers/mas/Commitments-for-MAS.pdf>. Model clauses are now a very popular notion for starting to solve our problems. The head of Microsoft Legal was talking about this in a blog post recently. A “legal stack” in CommonAccord means that a single outline can be built, and then the EU model clauses in each language can be mapped to the singular outline in turn. A contract outline has been put together that uses Dazza’s BLT ordering. This is why you can see {Business.Sec}, {Legal.Sec}, and then {Technical.Sec} as the sections in the outline. Andrew asks for great sources of Safe Harbor news. Here are some: Jon’s blog: DataLaw.net <http://datalaw.net/> Jon’s Twitter feed: @jonneiditz <https://twitter.com/jonneiditz> Jim’s Twitter feed: @CommonAccord <https://twitter.com/commonaccord> How does someone create their own documents/legal stacks/contracts? One can fork the code, or create pull requests, or… Jim has created some “pretend namespaces” at CommonAccord, such as “GHx” to represent the CommonAccord mirroring of GitHub repos living elsewhere, and “W” for the WWW generally, and “TW” for Twitter accounts. He also has “at” is for locations. Someday the app could go client-side so it could be everywhere. Ideally it should be understood as a file system by those who use it. The link at the top of the “Source” pages could then go and fetch the content live. The terms on the left of a stack, such as “DEO” for data-exporting organization, are just made up by the author. There’s no magic in it. It’s just a string that’s the name of a constant. Eventually the software will want to be able to handle some simple match, searches, etc. Andrew needs to have a well-described approach by mid-November. By late spring, they are looking to have the “commitments” and even some contracts settled. Can Andrew start to list the documents needed? We can start to put together draft versions, and assemble a stack. Andrew is currently trying to identify all the parties and transactions involved. He can share all that in a week or two. Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

2 1

Why HybridIDToken ?
by Roland Hedberg 23 Oct '15

23 Oct '15

In the examples in 3.5.4 and 3.6.2 ”http://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken” is given as an example of claim_token_format/format. I can’t see that Hybrid Flow ID Token provides the AS with any extra information compared to a ’normal’ ID Token that the AS can have any use of. Since the AS will most probably not have access to the code or the access_token value. Or am I missing something ? So, why choose it as an example. — Roland 'Look, that's why there's rules, understand? So that you think before you break ’em.’ - Terry Pratchett

2 1

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