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