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). 

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.