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

Eve Maler eve at xmlgrrl.com
Wed Aug 19 10:36:58 PDT 2009

Here's my attempt at better comprehensibility.

First observation: I'm not sure I understand the authorization/parties  
"key concepts" list below.  I'd say, rather, that there is a single  
act of authorization happening, with the opportunity for two kinds of  
constraints to be imposed on the authz decision -- both of them  
derived directly from the user's wishes.  The first kind of constraint  
is "policy" that can be imposed unilaterally, without the Consumer/ 
Client even knowing about it.  The second kind is "terms/conditions"  
that the Client must meet before gaining access.

(We can imagine a policy/term hybrid that conditions the Client's  
access on merely being informed: "Access this resource at your own  
risk; here are my policies..."  Do we need to consider a #scenario for  
this?  Something like "Informing a Consumer/Client of the user's terms  
without requiring positive confirmation of meeting/accepting them.")

Second observation: I think it would be useful for at least Christian  
and me, and likely others, to do a closer examination of the proposed  
flow in ProtectServe, and maybe compare/contrast with expectations and  
other models.  I dimly recall Christian's earlier experimentation with  
"4-legged OAuth" flows being a kind of mirror image of the PS  
proposal.  Perhaps we can see if there's general interest for this in  
tomorrow's call.

Towwards the goal of syncing up, please forgive me for any repetition,  
but here's a quick-reference summary of the ProtectServe flow  
(detailed view here: http://www.xmlgrrl.com/blog/archives/2009/06/02/protocol-peep-show/ 

0. User mediates the introduction of service provider to authorization  
manager.  This is almost entirely straight OAuth, allowing the SP to  
to make authorization requests of the AM later on when Consumers/ 
Clients request access to something at the SP.

1. Client tries to access a resource and gets sent by SP over to the  
AM to "register". (The resulting token, which we called an "access  
token" a la OAuth, doesn't actually guarantee access, just gives a  
unique correlation handle to the Client for all future use.)

2. Client retrieves the terms and conditions for this type of access  
to this resource and meets them to the AM's satisfaction.  The user  
can exercise her opportunity to demand real-time approval here, which  
would happen in some out-of-band way.

3. Client attempts access again; SP asks AM for policy decision and  
lets the Client in if the AM says it's okay.


On 18 Aug 2009, at 9:27 AM, Eve Maler wrote:

> 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...
> 	Eve
> 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
> 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