[Wg-uma] Proposed: Location scenario to replace Photo Set one

Eve Maler eve at xmlgrrl.com
Thu Aug 27 17:47:56 PDT 2009


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




More information about the Wg-uma mailing list