[Wg-uma] Google Wave scenarios (was Re: Proposed: Location scenario to replace Photo Set one)

Eve Maler eve at xmlgrrl.com
Fri Aug 28 07:24:16 PDT 2009

Thanks very much for this take.  I looked at the federation protocol  
when this was all announced, but couldn't actually make heads or tails  
of it :-), and anyway, having the f-word in the title is no guarantee  
that what's being federated is identities, or that authorization is  
being done...

My hope is that, if wave stuff is resource-oriented, it *should* be  
amenable to UMA protection just like anything else, but it would be  
cool if we could maybe generate a Wave scenario and then work with  
those folks to validate it.  I reached out to Ben Laurie on  
ProtectServe and then UMA, since we'd had quite a few "feed-based VRM"  
discussions mid-last year, but I don't think our work is really on his  


On 27 Aug 2009, at 7:36 PM, Joe Andrieu wrote:

> I'm following the Wave email lists. There is probably something  
> there worth looking into.
> Short version: permissions are flexible, but currently wide open,  
> and very much under development.
> Long version: two quotes and a link to the white paper on Access  
> Control
> ===
> ... permissions are wide open. At least in the current iteration of  
> Wave, there are no fancy graduated access controls. If you are a  
> member of the Wave, then you have full editing privileges. Rather  
> than setting hard controls, Wave provides contextual clues and tools  
> for users to negotiate control through the establishment of social  
> norms. This is much more like the way normal, F2F communication  
> (including classroom communication) works.
> source: http://mfeldstein.com/what-intrigues-me-about-google-wave/
> ===
> However, Wave also has a federation protocol:
> ===
> "a downstream wave provider can verify that the wave provider is not  
> spoofing wavelet operations, namely, it cannot falsely claim (1)  
> that a wavelet operation originated from a user on another wave  
> provider or (2) that it was originated in a different context. This  
> addresses the situation where two users from different, trustworthy  
> wave providers, say love.com and peace.com, are participants of the  
> a wavelet that is hosted on a malicious wave provider evil.com"
> source: http://www.nichesoftware.co.nz/blog/200906/first-impressions-google-wave
> ==
> http://www.waveprotocol.org/whitepapers/access-control
> Also, Wave uses XMPP, so I'm not sure how that protocol simplifies  
> or complicates UMA's OAUTH-based approach.
> From the white paper: "Each wave provider chooses how they  
> authenticate their users."
> So, I think there is probably a way to use UMA to authenticate  
> access at the wave-as-resource level for a particular wave provider,  
> but it would take someone more familar with the expected UMA  
> functionality to read the white paper and validate that.
> -j
> On 8/27/2009 5:47 PM, Eve Maler wrote:
>> Oh, and a by-the-way...  Does anyone know enough about Google Wave to
>> comment on whether UMA could apply to wave, wavelet, etc. access?  
>> When
>> we look at any sort of collaborative content like this, or wikis, or
>> traditional CMS's, vs. something like identity attributes, naturally
>> these *would* provide examples where potentially many people share  
>> write
>> access. However, I still hope a single resource owner/creator/ 
>> privileged
>> access-er could be the one granting all the subsidiary write access.
>> Eve
>> On 27 Aug 2009, at 5:42 PM, Eve Maler wrote:
>>> I agree about the usefulness of this conceptual tool! Good point  
>>> about
>>> the relative nature of the terms, and in fact the notion of
>>> "ownership" quickly gets complicated because ownership, as they say,
>>> is just shorthand for a "bundle of rights"
>>> (http://en.wikipedia.org/wiki/Bundle_of_rights).
>>> I'd be interested to see a plotting of "read" and "write" access
>>> rights to all these pieces of data, to get to the next level of  
>>> detail
>>> on the categories. My suspicion is that the category of items that
>>> truly allow coequal write access by multiple parties is pretty  
>>> thinly
>>> populated. To take an example from past InfoCard "relationship card"
>>> demos, there's a *set* of data I might share (co-own?) with United
>>> Airlines, but only they can populate the "miles flown" field and  
>>> only
>>> I can populate the "member email address" field.
>>> Eve
>>> On 27 Aug 2009, at 7:52 AM, J. Trent Adams wrote:
>>>> Iain -
>>>> I'm a total fan of the model you've illustrated, I think it's  
>>>> incredibly
>>>> powerful for describing the data buckets and flows. It works
>>>> particularly well when communicating with end users.
>>>> My only qualm in grounding the "my|your data" terminology in the  
>>>> UMA
>>>> work is that it seems to complicate the communication between the
>>>> stakeholders. The term "my" is by nature a relative one and  
>>>> depends on
>>>> who's using it.
>>>> Without wanting to destroy the conceptual model you've developed,  
>>>> would
>>>> it be reasonable to rename the data "petals/propellers" to  
>>>> something
>>>> more absolute that doesn't vary with a shifting point of view?
>>>> - Trent
>>>> Iain Henderson wrote:
>>>>> This looks like a great scenario Eve, location is going to be a  
>>>>> major
>>>>> issue going forward.
>>>>> I'll feedback on the VRM/ VPI scenario when you send it over. One
>>>>> other thought occurs (which may get resolved on the walk through  
>>>>> call
>>>>> later today). It is that i'm still not quite clear on the  
>>>>> terminology
>>>>> and descriptions of each of the parties (actors) that we intend to
>>>>> adopt. For example, I need to be clearer on the Authorisation  
>>>>> Manager
>>>>> term, as that's not one we use in the Mydex business (despite  
>>>>> being
>>>>> very much into user managed data sharing). I don't disagree with  
>>>>> the
>>>>> need for the term, just want to be aligned on it.
>>>>> Also on terminology issues, if possible i'd like to build a link  
>>>>> (or
>>>>> at least an understanding of the fit) between two areas of  
>>>>> terminology
>>>>> that are used in VRM/ VPI scenario's. I think that may help once  
>>>>> we
>>>>> get to deployment.
>>>>> The first area i'd like to align with would be the 'flower' model/
>>>>> propellor model in this blog post
>>>>> <http://kantarainitiative.org/wordpress/2009/06/iain-henderson-the-personal-data-eco-system/ 
>>>>> >
>>>>> of
>>>>> mine. I'm biased, but i'm pretty sure the terminology around 'my  
>>>>> data,
>>>>> your data, our data, their data and everybody's data' is robust  
>>>>> and
>>>>> mirrors reality. I'll be building this line of thinking out in a  
>>>>> lot
>>>>> of detail over the next few months in and around the VPI working  
>>>>> group
>>>>> - so alignment would be helpful.
>>>>> The second area i'd like to be aware of/ link to is the theme of  
>>>>> 'user
>>>>> driven services - as articulated in some detail by Joe Andrieu  
>>>>> here
>>>>> <http://blog.joeandrieu.com/2009/04/26/introducing-user-driven-services/ 
>>>>> >.
>>>>> That therefore links to the characteristics of user driven  
>>>>> services,
>>>>> and also into two other terms that might be helpful - 4th party
>>>>> services (that work for the individual/ buyer) and 3rd party  
>>>>> services
>>>>> (that work for the organisation/ vendor).
>>>>> Lots to discuss there, but if we anchor our terminology early on  
>>>>> then
>>>>> I think that will pay off down the track.
>>>>> Regards
>>>>> Iain
>>>>> On 27 Aug 2009, at 01:34, Eve Maler wrote:
>>>>>> I took an action at last week's meeting to revise the Photo Set
>>>>>> scenario based on our discussion. We didn't have a conclusive  
>>>>>> answer
>>>>>> about whether we should include the "multiple resources from  
>>>>>> multiple
>>>>>> sources" aspect; I've decided not to include it, since my
>>>>>> conversation with Iain earlier this week about VRM scenarios
>>>>>> convinced me it will get covered elsewhere (in email from me,
>>>>>> sometime before tomorrow!). So here is my proposed replacement.
>>>>>> #Scenario: Controlling Two-Way Sharing of Location Information
>>>>>> Distinctive aspects:
>>>>>> • Potentially two-way service access. Think of it as a read-write
>>>>>> operation, or an HTTP GET/POST/PUT/DELETE.
>>>>>> • Not only inspired by OAuth's authorized interactions, but  
>>>>>> relies on
>>>>>> integrating with OAuth-enabled services specifically (though not
>>>>>> without UMA-related changes to OAuth endpoints).
>>>>>> • Raises an issue (see more about this below) about the potential
>>>>>> need for an AM to learn an SP's capabilities around
>>>>>> operation-specific policy
>>>>>> Actors:
>>>>>> • User
>>>>>> • Authorization Manager
>>>>>> • Service Providers (some of which are also Consumers)
>>>>>> • Consumers (some of which are also Service Providers)
>>>>>> Description:
>>>>>> Today, many Web 2.0 services are beginning to offer users  
>>>>>> features
>>>>>> that depend on connections with other third-party services, using
>>>>>> OAuth to forge the connection. A classic example is sharing your
>>>>>> whereabouts between services. Since location information can be
>>>>>> privacy-sensitive, and since people can end up "chaining"  
>>>>>> services
>>>>>> this way, it's especially important for a person to know and  
>>>>>> control
>>>>>> where this information is flowing to.
>>>>>> In this scenario, a user of FireEagle, Dopplr, and BrightKite  
>>>>>> wants
>>>>>> to connect them all up to be able to read *and* write her  
>>>>>> location to
>>>>>> all of them, and she wants to get a global view of who's  
>>>>>> allowed to
>>>>>> do what, and change permissions in a coordinated way.
>>>>>> Below is a screenshot showing that FireEagle and Dopplr do have  
>>>>>> the
>>>>>> capability today to have two-way location information flow. Our  
>>>>>> user
>>>>>> wants to be able to see this "combinatorily", for all location
>>>>>> services and indeed for all such services on the web that she  
>>>>>> chooses
>>>>>> to use for hosting any data or content.
>>>>>> (I should probably add several use cases to this, that flesh  
>>>>>> out the
>>>>>> various policy propositions highlighted in the issue text  
>>>>>> below, but
>>>>>> let's discuss it on a call first.)
>>>>>> <pastedGraphic.png>
>>>>>> Add a note to #Issue: Policies Specific to the Web Resource Type
>>>>>> Related to: Controlling Two-Way Sharing of Location Information
>>>>>> (along with other scenarios)
>>>>>> (replace the language about the Photo Set scenario with this:)  
>>>>>> In the
>>>>>> Controlling Two-Way Sharing of Location Information scenario,  
>>>>>> note
>>>>>> that FireEagle allows a user to share location only at the city
>>>>>> level, and this level happens to be chosen for the connection  
>>>>>> that
>>>>>> authorizes Dopplr to read the FireEagle location (a different  
>>>>>> level
>>>>>> can be chosen for each application that reads location from
>>>>>> FireEagle). As it happens, Dopplr does not offer the same policy
>>>>>> capability. Without having to teach UMA generically about all the
>>>>>> possible policy options specific to all the kinds of  
>>>>>> information in
>>>>>> the world, is it possible for each SP to teach each AM about the
>>>>>> policy options it offers, in some way that lets the the  
>>>>>> relationship
>>>>>> manager application surrounding the AM present user interface  
>>>>>> options
>>>>>> to see and select these policies? Seeing may have less protocol
>>>>>> impact than selecting, and seems to be a minimum value-add if the
>>>>>> goal is to allow OAuth users to get a global view.
>>>>>> Eve Maler
>>>>>> eve at xmlgrrl.com <mailto: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
>>>>> Iain Henderson
>>>>> iain.henderson at mydex.org <mailto:iain.henderson at mydex.org>
>>>>> This email and any attachment contains information which is  
>>>>> private
>>>>> and confidential and is intended for the addressee only. If you  
>>>>> are
>>>>> not an addressee, you are not authorised to read, copy or use the
>>>>> e-mail or any attachment. If you have received this e-mail in  
>>>>> error,
>>>>> please notify the sender by return e-mail and then destroy it.
>>>>> ------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> Wg-uma mailing list
>>>>> Wg-uma at kantarainitiative.org
>>>>> http://kantarainitiative.org/mailman/listinfo/wg-uma_kantarainitiative.org
>>>> --
>>>> J. Trent Adams
>>>> =jtrentadams
>>>> Profile: http://www.mediaslate.org/jtrentadams/
>>>> LinkedIN: http://www.linkedin.com/in/jtrentadams
>>>> Twitter: http://twitter.com/jtrentadams
>>> 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
> -- 
> Joe Andrieu
> joe at switchbook.com
> +1 (805) 705-8651
> http://www.switchbook.com

Eve Maler
eve at xmlgrrl.com

More information about the Wg-uma mailing list