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

J. Trent Adams jtrentadams at gmail.com
Thu Aug 27 07:52:26 PDT 2009


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




More information about the Wg-uma mailing list