http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes... 2016-07-22 - Review UMA Roles and Responsibilities Primer https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHKQ... Attending: Eve, John, Sal, Ann, Kathleen, Colin, Adrian, Jon, Scott (Maciej regrets) We reviewed the primer and made changes dynamically. We discussed whether "Alice and Bob" are appropriate as standard RO and RqP names, given their history as equal peers in PKI, vs. their asymmetrical nature in UMA. UMA's historical goal is to empower the RO role in an ecosystem fashion a la Eve's 2008 diagram from the Digital Contracts MIT event, even if instances of a running UMA protocol are indeed asymmetrical, since the RO has an "agent" – the AS – working on her behalf whereas the RqP doesn't. Of course, there's an admittedly asymmetrical part of the UMA protocol called trust elevation where the RqP may have to supply or direct services to supply information about themselves, which could be UMA-protected, so the RqP could have an "agent" acting on their behalf too. In short, while they're not peers at an "individual instance of the protocol" technical level, it's possible that they're similarly protected at the technical, contractual, and regulatory layers. Self-regulatory structures are the common theme coming out of the list of "Additional Discussion Topics", which we spent a lot of time on. Some of those structures will be shaped by supply chain necessities – see, for example, how UPS and FedEx end up with similar contractual outputs. We think that once we have our "Tech/Contract/Reg" framework, we could spin out white papers on each of the additional discussion topics, and likely liaise more effectively with the IDoT, IRM, and BSC efforts in Kantara. (Be sure to see the notes so far http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29+... from the BSC group.) We reviewed the scenario in the Tech section. Scott asked: Do we want to draw the equivalence between the federated identity progress and federated authorization? Eve thinks this depends on whether we're writing for an audience that understands federated identity trust frameworks. Adrian goes by the "There's only one Alice" mantra – the AS shouldn't be "domain" (sector) specific. This is the personal AS viewpoint. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl