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-07-09
Attending: Eve, Lisa, Adrian, Domenico, Andi, Thomas, Tim, Colin The chosen term Representative is now in the Legal Parties tab.
AI: Tim: Develop a suitable definition for Representative, sourced to any legal sources as he sees fit (akin to how other definitions are done in the original report).
What do we say about consent? We bundle a series of actions that the RRA is "authorized to delegate" to the ASO, including "access control, consent, and licensing functions". What does our repeated phrase "manages the sharing of X's resources" in our use cases? With respect to UMA, it specifically means the actions of the AS. Thinking about something like a "vault" or "wallet", UMA doesn't have a technical entity like this, though we know of at least one extension that does, so maybe this could come into play officially eventually.
What is the "state" language about? It's techie language. Many of the use cases would reflect life cycle changes, as in literally a human's life cycle (connected to parties). These tend to be relatively slow and predictable in the scheme of things. Permissions might need to change in response to this. Some might be much faster and more dynamically changing, like temperature changes or associations between people that are more short-lived, like Uber rides or similar.
Why is UMA itself insufficient for this relationship work? UMA-based sharing manages only what a resource owner can control. Adding the "IRM" layer enables us to capture both all the steady states where the "endpoints" aren't the ultimate "end parties", and all the transitions between steady states. So our next significant work here is to define this state machine.
AI: Lisa and Cigdem: Press ahead on the state machine depiction approach.
A "task force" will work on this and we will next meet two weeks from now.
2019-07-16
Attending: Eve, Lisa, Domenico, Cigdem, Mark, Tim (regrets: Andi, Colin)
FYI, Eve can't make IETF 105 in person after all. She may try to attend the OAuth.XYZ portion of it remotely (it's being presented on Tuesday next week).
2019-07-09
Attending: Eve, Lisa, Adrian, Domenico, Andi, Thomas, Tim, Colin, Nancy (regrets: Cigdem, Nancy)
Eve briefly walked through the paper that she and Lisa have submitted to the IEEE ComSoc CfP. It's called Beyond Consent: A Right-to-Use Licensing Agreement for Mutual Agency. The argument made by the paper is that digital consent and Terms acceptance (perceived as consent) are failing and don't meet a strict definition of consent (Nancy Kim's Consentability framework is used), and using a Me2B lens (centering on the user of the digital services) shows that a licensing agreement is more appropriate. A taxonomy for license agreement contents is proposed, and some challenges are discussed. The paper points to the UMA report where a license is already proposed, but starts "earlier" in the personal data usage chain to be more comprehensive.
...
- 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
...