Ah, but whereas it’s relatively easy for two parties to work something out dynamically, we don’t often find real-world examples of five(-plus) parties interacting in such a way that the internal pairwise interactions are all required to be able to take place dynamically — and each direction may have unique needs, so you can’t even save effort by treating anything as bidirectional. So the complexity level goes way up. RO/AS (potentially, if they didn’t build it themselves), RO/RS, AS/RS, RO/RqP, RqP/C, C/RS… (The premise of a “trust framework” is that where dynamism is unacceptable for whatever reason, it lowers the friction of an ecosystem like this because each pair doesn’t has to figure things out afresh.) Eve

On 23 Sep 2015, at 4:52 AM, Adrian Gropper wrote:

This is a very helpful summary and I agree that it focuses attention on the right things.

There's one thing I take issue with: The wonderously named Free Love buisiness model is the least complex of the three in the sense that cash transactions, barter, and yes, love, are two-party contracts between the RO/AS and the RS. The other business models involve at least three parties in the root Resource Set Registration contract. As I remember, free love was never about federation.

Power to the people!

Adrian

On Tuesday, September 22, 2015, Eve Maler mailto:eve@xmlgrrl.com> wrote: This is the message I promised legal subgroup folks last week, after gathering feedback from a few folks. I heard a couple of themes:

Appetite to cut to the chase and discuss actual "business models” and concrete legal constructs (e.g., finally discussing licensing) Agnosticism about how we capture and store our results and deliverables (GitHub, Confluence, Word, whatever)

These both make a lot of sense to me, particularly in the context of our tightening timeline. There’s always a danger of Zeno’s Paradox of Standards-Making: Before you can get halfway done, you have to get halfway to that intermediate point, and halfway to that second point, and so on, such that you can never finish. :-) So here are the tasks I recommend we undertake.

1. The meta-use cases — liability tensions, if you will — of most interest have been staring us in the face the whole time (they’re in our mission statement), and I suggest we focus on these two meta-use cases exclusively for the 2015 period:

RS is concerned about outsourcing protection functions to AS RO is concerned about the accuracy and success of granting access to RqP given incomplete trust and the intermediaries involved

If anyone has others they would like to make a case for, we can put them on the list and discuss (briefly) whether reprioritizing makes sense.

2. “Business model” is a term that I heard in the conversations. It’s in quotes because I don’t want to scare away anyone who would prefer to think of this in more Alice-friendly terms; it simply means is the nature of the ecosystem where the parties interact (I sometimes call this a “deployment ecosystem” or a “topology"). We need to prioritize the business models for which our subgroup needs to create outputs. Here are a few to consider, going from simpler/smaller to more complex/larger:

Organizational consumer-facing access federation: Similar to the corporate consumer-facing identity federations of today. Enterprise E serves as both AS and IdP to its end-user customers, who are the ROs. RqPs might be customers as well, or also users with a more tenuous relationship to enterprise E. The RS’s and clients might be run by enterprise E, or possibly also by some partners P, who have been well vetted in advance and whose service and app relationships were set up statically. Each RO experiences the AS as covering the authorization of some fairly limited set of resources in their “online world” (e.g. vertical- or vendor-specific), rather than a potentially comprehensive set. The federation might or might not cross jurisdictional boundaries. Example: Government-to-citizen attribute-sharing and delegation platform with a single government-run AS.

Industry access federation: Somewhat similar to the social login identity federations of today. A variety of services and products SP find it valuable to standardize on a method of outsourcing authorization, and a few authorization players A have arisen that are willing to play the AS role, such that end-user ROs are able to choose, by (something approximating) free-market action, the AS they would like to use when engaging with each SP. However, there may be market forces that restrict the choices A presented at each SP among which an RO could choose, producing a “NASCAR effect". Options that are "RO-built/bought/run" are, as today, much less likely to be viable in the market, but there is no structural reason that they would be excluded. The environment is fairly heterogeneous, with any AS/RS/client matchup possibly representing three different organizations, but each required pairwise relationship is likely established in a static fashion, as today. Example: Consumer IoT marketplace with a few popular AS platforms to choose from (imagine WeMo etc.).

Free-love access federation: :-) An analogue to the Platonic ideal of identity federation oft-imagined today. All parties can meet and establish trust dynamically as required; for example, an UMA client can acquire OAuth client credentials at an AS at the moment of need, and so can an UMA RS, with any business concerns such as execution of terms of service handled dynamically. ROs can freely choose, build, buy, or run their own AS. Example: The desired end-state of the global healthcare market, with IoT and consumer elements mixed in.

If you have others in mind, or want to adjust these, great.

3. We need to determine roughly what our outputs should look like, so we know what we’re driving towards. Is it model clauses? Something different/more? Let’s just get an idea.

4. If we think about the two meta-use cases in light of each of the business models of interest, and in light of what we’re supposed to deliver, no doubt the experts in the room will notice all the things we’re missing! We need to develop a list of unknowns without which we can’t finish our work. I’m hearing that this could be anything from jurisdiction to “policy” (not authorization policy, something else? policy framework?) to use case specifics to whether we’re using a licensing model vs. a contract model!

Please let me know what you think of this approach, on the list or separately. I’ll send an agenda with dial-in details as usual; the above may take us two meetings’ worth of time to go through…but maybe not, if we’re focused and try to do some homework ahead of time.

Thanks!

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com javascript:_e(%7B%7D,'cvml','xmlgrrl@gmail.com');

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/ http://patientprivacyrights.org/donate-2/

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

I'm losing the thread of this conversation. To me, the federation of access authorization is an option on top of the baseline of an RO-built authorization server just as taking credit cards is an option on top of cash as a basis for commerce. I assume this debate between Eve and me will now be subsumed by the legal discussion and may become moot in time. As far as Jim's question, I remain focused on the ROI contract between RS and RO as the core link to agency law and the foundation for our work. Adrian On Fri, Sep 25, 2015 at 9:12 AM, James Hazard wrote:

In (slight) anticipation of our call:

Would it make sense to list the legal-ish documents that would conventionally be involved in each scenario, in some high frequency or high interest uses? Then begin to fill in what those documents look like (normatively and, to the extent that there are current patterns, currently)? Would these be consents, requests, ToU. Where does the legal boilerplate hit the legal road?

On Sep 23, 2015, at 2:47 AM, Eve Maler wrote:

2. “Business model” is a term that I heard in the conversations. It’s in quotes because I don’t want to scare away anyone who would prefer to think of this in more Alice-friendly terms; it simply means is the nature of the ecosystem where the parties interact (I sometimes call this a “deployment ecosystem” or a “topology"). *We need to prioritize the business models* for which our subgroup needs to create outputs. Here are a few to consider, going from simpler/smaller to more complex/larger:

- *Organizational consumer-facing access federation:* Similar to the corporate consumer-facing identity federations of today. Enterprise E serves as both AS and IdP to its end-user customers, who are the ROs. RqPs might be customers as well, or also users with a more tenuous relationship to enterprise E. The RS’s and clients might be run by enterprise E, or possibly also by some partners P, who have been well vetted in advance and whose service and app relationships were set up statically. Each RO experiences the AS as covering the authorization of some fairly limited set of resources in their “online world” (e.g. vertical- or vendor-specific), rather than a potentially comprehensive set. The federation might or might not cross jurisdictional boundaries. Example: Government-to-citizen attribute-sharing and delegation platform with a single government-run AS.

- *Industry access federation:* Somewhat similar to the social login identity federations of today. A variety of services and products SP find it valuable to standardize on a method of outsourcing authorization, and a few authorization players A have arisen that are willing to play the AS role, such that end-user ROs are able to choose, by (something approximating) free-market action, the AS they would like to use when engaging with each SP. However, there may be market forces that restrict the choices A presented at each SP among which an RO could choose, producing a “NASCAR effect". Options that are "RO-built/bought/run" are, as today, much less likely to be viable in the market, but there is no structural reason that they would be excluded. The environment is fairly heterogeneous, with any AS/RS/client matchup possibly representing three different organizations, but each required pairwise relationship is likely established in a static fashion, as today. Example: Consumer IoT marketplace with a few popular AS platforms to choose from (imagine WeMo etc.).

- *Free-love access federation:* :-) An analogue to the Platonic ideal of identity federation oft-imagined today. All parties can meet and establish trust dynamically as required; for example, an UMA client can acquire OAuth client credentials at an AS at the moment of need, and so can an UMA RS, with any business concerns such as execution of terms of service handled dynamically. ROs can freely choose, build, buy, or run their own AS. Example: The desired end-state of the global healthcare market, with IoT and consumer elements mixed in.

If you have others in mind, or want to adjust these, great.

3. *We need to determine roughly what our outputs should look like*, so we know what we’re driving towards. Is it model clauses? Something different/more? Let’s just get an idea.

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

-- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/