[Wg-uma] Proposed: Location scenario to replace Photo Set one
iain.henderson at mydex.org
Thu Sep 3 00:20:23 PDT 2009
Hi Trent, I take your point about terminology - but for me it is what
it is for a very specific reason. This model is primarily a VRM tool,
i.e. in classic Doc parlance it is about building capability (in this
case just education) on the side of the individual that will
utlimately help organisations do what they are currently attempting to
do in a sub-optimal manner. So for me, the term's 'My Data' and 'Our
Data' are deliberately simplistic and friendly to the individual
perspective - and thus not aimed at organisations.
That said, i'll be spending some time on this model and going to the
next level with it before the Kantara meeting - so maybe my update
will include a meta data layer to allow organisations to view it in
their own context.
I'll ping the group with an update when i've done so.
On 27 Aug 2009, at 15:52, J. Trent Adams wrote:
> Iain -
> I'm a total fan of the model you've illustrated, I think it's
> 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
> who's using it.
> Without wanting to destroy the conceptual model you've developed,
> 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
>> 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
>> > of
>> mine. I'm biased, but i'm pretty sure the terminology around 'my
>> 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
>> - so alignment would be helpful.
>> The second area i'd like to be aware of/ link to is the theme of
>> driven services - as articulated in some detail by Joe Andrieu here
>> 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.
>> 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
>>> about whether we should include the "multiple resources from
>>> 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
>>> 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
>>> • User
>>> • Authorization Manager
>>> • Service Providers (some of which are also Consumers)
>>> • Consumers (some of which are also Service Providers)
>>> 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
>>> 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
>>> wants to be able to see this "combinatorily", for all location
>>> services and indeed for all such services on the web that she
>>> 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.)
>>> 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
>>> 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
>>> 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>
>>> Wg-uma mailing list
>>> Wg-uma at 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
> J. Trent Adams
> Profile: http://www.mediaslate.org/jtrentadams/
> LinkedIN: http://www.linkedin.com/in/jtrentadams
> Twitter: http://twitter.com/jtrentadams
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.
More information about the Wg-uma