2017-11-17

Attending: Eve, Jim, Tim, Kathleen, Colin, Bjorn, Mark

Tim asked: To avoid many many contracts, is it possible to have all parties go through the ASO?

• Eve: Most circumstances today leave Alice accepting the ASO's and RSO's ToS/PN as a contract of adhesion. (Also, presumably, the use of each RS comes at a time when Alice decided to use it, and the choice to sew together each RS with the AS – authorizing PAT issuance -- comes at an appropriate time also, so, the experience is at her discretion.) Our work to add to templated clause text can strengthen the provisions of these contracts even if there are several preceding the license phase.
• Eve: In some deployment ecosystems, the ASO may be singular because other parties are aggregated into it (ASO + singular RSO, ASO + RSO + CO, etc.). In these cases, the process of accepting an initial (non-UMA) ToS/PN and authorizing a later PAT, e.g., could be rolled into one.
• Jim and Kathleen: In some cases, Alice may have power, either because the RO is "AliceCo" (not directly in our framework's scope for now) or because the law gives her more power (e.g. "patient right of access") – effectively, the Alices have been "aggregated". These effectively give strength to the templating we can do.

Jim: Regarding improving the circumstances of the "little" party wrt the "big" party, you can do it through influencing law (out of scope for our group), you can do it through intermediaries, you can do it through model terms/template clauses (the latter now being this group's favored phrase – so this would be our group's role in this ecosystem), and you can do it through adopting processes that enforce industry behavior that manage compliance risk for "big" parties (this is how others could use our deliverables – maybe IACCM, Pan-Canadian Trust Framework effort, other countries, other industries, etc.). We can't make anyone use this framework; rather, we want to make it as easy to use, adopt, adapt, and profile as possible.

These links illustrate templating and ecosystem chains:

http://www.commonaccord.org/index.php?action=source&file=Dx/Acme/09-EU-US-DataTransfer/Acme_UK/0.md

http://www.commonaccord.org/index.php?action=xEdit&file=G/TechContractsCom-ITMA-CmA/Form/0.md#GeneralTerm.Data.Sec

Eve has reached out to the people at Origo regarding their use of UMA (V1, however) and their potential need for ToC/PN that are protective of privacy rights in a standard way.

https://pensionsdashboardproject.uk/saver/about-the-pensions-dashboard/

http://www.origo.com/news/Kenneth_May_Demonstrates_Delegated_Authority_Pensions_Dashboard.aspx

https://www.ipe.com/countries/uk/uk-government-backs-pension-dashboard-project/10021187.article

Let's plan to focus on this as a candidate case study/use case in the document. It has properties of strong authentication, a likely "design pattern" of sharing we'll see again, a government friend for Alice in negotiating the terms ("you and what army?" "this army!"), non-co-located services/parties, mappings to many of the characteristics of the use cases we gathered in deliverable #1, people who profiled UMA for real use already, etc. It only doesn't have UMA2, but we could work around that.