[Wg-uma] New Scenario "Distributed Social Networks" and a modular specification

Eve Maler eve at xmlgrrl.com
Tue Aug 18 09:27:22 PDT 2009

Ugh, this has to be one of the more incomprehensible emails I've ever  
written.  Sorry about that.  I'll try to get proper time to re-think  
and re-explain later...


On 18 Aug 2009, at 7:15 AM, Eve Maler wrote:

> On 17 Aug 2009, at 12:14 AM, Christian Scholz wrote:
>> Hi!
>>> Christian-- Thanks very much, for many things!  The new scenario,  
>>> the modularity suggestions, and your very active participation in  
>>> today's call.
>> You are very welcome :-) And also thanks for explaining your  
>> scenarios.
>> The key concepts I see in those scenarios for now are:
>> - authorization between two parties (three with user)
>> - authorization between more than two parties (plus user)
>> - policy negotiations between all those parties
> I *think this is right.  The way I'd put it is: The basic template  
> is to let the AM impose the user's chosen authorization policies  
> through decisions it makes when the SP asks if it can grant the  
> Consumer access, and to give the Consumer choice around meeting the  
> user's terms into the Consumer's hands at the point of authorized  
> access.  Policies can be imposed unilaterally; terms require someone  
> to agree to/meet them.
> The calendar scenario is very basic, allowing its use case to  
> explain the bare bones of how we came up with the user/AM/SP/ 
> Consumer flow for data sharing.  The photo set scenario adds the  
> wrinkles of complex service access and an explicit requirement for  
> OAuth integration.
>> There might also be a similar scenario btw with virtual worlds  
>> based on Linden Lab's OGP approach which also is valid for an  
>> approach around a service catalogue. The main concepts are the same  
>> as virtual worlds are also social networks but one key difference  
>> might be that it's annoying to get asked any
>> question in case you move from one simulator to another (e.g. by  
>> walking over a border). Here some means needs to be found to make  
>> this authorization/policy step more automatic maybe limited to a  
>> certain domain or by some means of a web of trust approach. But I  
>> can write more details about that in a different mail.
> That would be great.  Infinity Linden and I have managed to spend a  
> little time together, reviewing her needs and the ProtectServe  
> proposition, but I'd love to get virtual-world scenario into the doc  
> that focuses on the special characteristics needed.
>>> I agree with an approach of small modular specs with extension  
>>> points/"interfaces" to other specs -- which may be our own, may  
>>> come from elsewhere, or in some cases may not even exist yet (as  
>>> long as we have a temporary workaround or a default).
>>> We'll have to try your specific extension point suggestion and see  
>>> if it will work.  If we approve a scenario that involves, say,  
>>> just auditing access without imposing terms/policies (this is  
>>> something I've thought about!), then it would make this  
>>> demarcation point even more obviously necessary.
>> Well, policy negotiations could always happen in the same step in  
>> which a service (OAuth now calls them clients IIRC, btw) wants to  
>> access a server and again needs to retrieve a token. This could be  
>> basically a reissueing of a token which also might include policy  
>> information. I don't know all OAuth extensions but in case we need  
>> to create one ourselves we can also choose an extensible format  
>> (e.g. XML, maybe XRD would even work in case we express policies as  
>> <Rel> elements) and either policy information is around or it isn't.
> Yikes, I need to catch up on the OAuth changes.  So what was a  
> Consumer is now a client?  Not bad; an overall improvement.  It sort  
> of mirrors the terminology in the Liberty identity web services  
> framework: "web service client" or WSC, vs. "web service provider"  
> or WSP. :-)
> The essential thing that we are trying to add with UMA is an  
> externalized authorization function, which can not only track but  
> control access on the user's behalf, even when the user deals with  
> many different services and clients (hopefully I have that right).   
> I've heard of a notion of "sticky policies" that travel with the  
> content they're supposed to apply to, but I worry a lot about how  
> closely this skates to DRM, and how many technical problems it buys.
> The most popular policy format in the enterprise world is XACML, an  
> XML-based format expressly designed for authz.  And there are  
> starting to be interesting XACML profiles, like "Policy  
> Constraints", which may be directly relevant to us and which don't  
> look scary, even if ordinary users happen upon it:
> http://lists.projectliberty.org/pipermail/sig-vpi_lists.projectliberty.org/2008-November/000009.html
>> But I haven't thought about the actual flows needed yet and if they  
>> actually go into the right direction. But if policies are stored in  
>> the AM (or at least the set of granted policiy elements) the AM  
>> needs to ask the server for a new token anyway and can also pass  
>> policy information in case they have changed since the last time  
>> (and how long would a server need to cache that information?).
> We probably do need to do some technical sync-up, as the AM is in a  
> position of granting tokens, not asking for them...  This is where I  
> think your original sketch of a 4-legged flow and the ProtectServe  
> flow were sort of mirror images of each other.  Figuring this out  
> would be very useful for us (and everyone) to get the bigger  
> picture, I suspect.
>> But as I have no clear picture of the technical flow right now I  
>> guess this can be discussed later in detail (as long as we know we  
>> need to discuss it).
>> cheers,
>> Christian
>> PS: As told on the call I won't be available for this week's call  
>> as I am on the road. Will be back next week.
> We'll miss you!  I've added your name under the Regrets header on  
> our fledgling page for the 2009-08-20 meeting.
> We should think about scheduling an extra hour -- perhaps the hour  
> before the next call that Christian can attend -- to review the  
> current flows on the table and compare technical notes...
> 	Eve
> Eve Maler
> eve at xmlgrrl.com
> http://www.xmlgrrl.com/blog
> _______________________________________________
> Wg-uma mailing list
> Wg-uma at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma_kantarainitiative.org

Eve Maler
eve at xmlgrrl.com

More information about the Wg-uma mailing list