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 <eve@xmlgrrl.com> 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