Standing agenda for 2019: Work on producing our second legal-business framework report by September, initially focusing the work on use cases that illustrate each of our mappings from business relationships (and changes in those relationships) to UMA technical artifacts.
...
"Legal" topics are currently being covered in a separate legal-business framework meeting series. See the UMA calendar for details.
2019-09-24
Attending: Eve, Cigdem, Domenico, Nancy, Tim, Vlad, Sal
At the DS-RRA wrangling layer where UMA doesn't have any artifacts, there will typically be a lot of identity and access management taking place. What technical artifacts can we expect to be used there? Typically many proprietary ones, but also potentially some standardized ones, such as federation standards like SAML and OIDC, maybe provisioning standards like SCIM, maybe auditing-friendly standards like consent receipts, etc. We have already mentioned consent receipts in our "devices and artifacts" capture.
The topic discussed last time was: Could/How could UMA be used to achieve user control of the initial user relationship with a service provider? The answer in today's world is that UMA was designed with today's imperfect situation in mind, which presumes opt-in cookie consent, opt-in terms and conditions, opt-in OAuth app connections, and opt-in AS-RS connections for UMA, which are all sub-optimal. However, the Lisa/Eve paper proposes an architectural way forward for fixing these broken patterns, which is to use the "Open Banking trick" for intent registration. The trick uses the nexus of the Open Banking APIs and OIDC request objects to allow transaction authorization of payment of a specific amount of money for a single payment, vs. authorization of an OAuth scope for an indefinite period. Theoretically, this "intent registration" ahead of time by a user at a client app (TPP) could be used to allow transactional (one-time) "intent registration" of user-centric terms and conditions, not just payment of money. Flows still to be worked out for each use case of user/service interaction, of course!
Cigdem had commented about moving up the Legal Parties discussion in the document and we agree. She will do some "invasive" editing of the doc.
Eve can't make Oct 8th or Oct 15th. It sounds like we have critical mass of people to join on the 15th so Eve will ensure someone can open the bridge on that day. In the meantime Cigdem will edit the doc.
We haven't discussed Nancy's latest submitted set of use cases, including healthcare and banking. One of Eve's goals is to include as many submitted real-life use cases as possible. We've already got quite a few. She's started a couple of templates for some more in the "mapping" slide deck.
2019-09-17
Attending: Tim R, Lisa L, David Thelander, Pete Palmer, Ruth P (Kantara)
The group discussed whether and how UMA currently treats first order legal relationships (i.e. the creation of the initial legal relationship between the consumer/data subject/legal representative and the service provider and/resource server operator. For purposes of this first order legal relationship, the group further discussed the possibility of deploying a 'reverse EULA' as discussed in the recent paper published by Lisa and Eve. Lisa reported that the Me2B organization has a legal subcommittee that is now actively developing model 'reverse EULA' language. It was suggested that UMA might collaborate with Me2B on this effort. [Editor's note: The Proposed UMA Business Licensing Model contemplates that the ASO, using an Access Contract vehicle that authorizes licensing, is the entity that creates the first order legal relationship with the Service Providers and Resource Service Operators.]
Follow-up actions: Lisa has offered to share information on the Me2B efforts to create model 'reverse EULA' terms. In particular, Scott David has prepared excellent initial legal materials. David T has legal expertise with software licensing and also offered to assist with developing standard licensing terms.
2019-09-10
Attending: Eve, Andi, Nancy, Domenico, Vlad, Cigdem
...
- Agreement that turns a service provider into an RSO (wasn't included in business model report)
- Agreement that turns a service (or app) provider into a CO (wasn't included in business model report)
- Agreement that enables a Person to act on behalf of a Data Subject [which puts them into position to act as a Resource Owner -- otherwise RO=DS]
- Agreement(s) that delegates authorization for an ASO to grant access permissions on behalf of an RO (typically Ts & Cs, privacy notice, EULA...)
- Agreement(s) that delegates authorization for an RSO to manage resources on behalf of an RO (typically Ts & Cs, privacy notice, EULA...)
- Agreement that enables a Person to act on behalf of a Requesting Party [which puts them into position to act as a Requesting Party Agent -- otherwise RqPA=RqP]
- Agreement that delegates access seeking to a CO on behalf of a Requesting Party
- Agreement that delegates permission to know and persist personal data to an ASO on behalf of a Requesting Party
Jim H has started on a CmA version of the model.
...
Arrgh, so close! Tim and Eve will try and wrap up all the remaining comments in the doc by Monday and get the e-ballot out.
2018-01-12
Attending: Eve, Colin, Tim
...