cs at comlounge.net
Tue Sep 1 15:17:06 PDT 2009
Am 01.09.2009 23:43, schrieb Eve Maler:
> Perhaps we're getting closer! If User as entity #1 gets consensus, and
> "... Service" gets consensus, then we can get down to arguing about the
> three instances" of "...".
> Does Authorization Service work for entity #2?
> Could we be happy with Client Service for entity #4? I'm finding myself
> quite comfortable with it.
I sorta find the word a bit confusing because they all have "Service" in
Why is publisher and subscriber bad btw? Isn't one service subscribing
to an API of another service which publishes that API? They even have
some sort of contract eventually.
And as I said before, I find everything related with "Storage"
problematic because it might not be a storage but e.g. an API which
opens some door or so (so here also "Data" would be problematic).
> I'm starting to like "Hosting Service" for entity #3, since a client
> service that posts data into a hosting service is simply doing as the
> user bids -- storing some data in (one of) their chosen host(s). Using a
> straight OAuth example to test the read-write situation, let's say the
> location service Dopplr is acting as an OAuth Client to FireEagle's
> OAuth Server. We may also have an UMA Authz Service that mediates
> whether Dopplr as an UMA Client Service can add location data to
> FireEagle as an UMA Hosting Service. Not bad, I'd say.
> I'm wary of "Data" because I'm hoping we can use the same infrastructure
> for "data" (small fields, identity attributes, etc.) and "content"
> (user-generated content, photos, etc.). Not that these are pure or
> well-defined terms, but I'd love to be inclusive.
> (I'd be wary of "Storage", should anyone suggest it, since it would
> sound like "storage as a service" cloud offerings...)
> By the way, the repetition of "Service" may help with the "relationship
> manager" problem too. Let me try out an alternative: an "access manager"
> could offer several "services": it offers an authorization service at a
> minimum, but it might also offer a hosting service (for personal data
> not hosted elsewhere) and a client service (for keeping track of the
> user's agreements to access the data of others).
> On 1 Sep 2009, at 1:12 AM, Joe Andrieu wrote:
>> This is getting close.
>> I like User, especially as it is in sync with both UMA and UD-VPI names.
>> I also like all of the other components as "services". The Client
>> Service term might be improved, but I think it clarifies that the we
>> don't mean the client software (user-agent) or a more traditional
>> client in a client/server sense. Most importantly, I think "services"
>> as a common referent in 2,3, and 4, distinguishes them from the live
>> person of the user.
>> However, I think #3 "responder service" doesn't quite capture the
>> essence. That service isn't defined by the fact that it responds. All
>> interactive services do respond to input. It's the nature of
>> Rather, I think the #3 service as more of a data host or data
>> provider. It is where the data lives that is being authorized for and
>> accessed through UMA. It is the source of the shared information.
>> My own jargon would suggest "Datastore Service", but that may be too
>> jargony. =)
>> How about Data Service? Or Data Hosting Service? Or Hosting Service?
>> On 9/1/2009 12:35 AM, Diego R. Lopez wrote:
>>> On 1 Sep 2009, at 03:15, Eve Maler wrote:
>>>> What about the following as "clean" set of terms (that still has
>>>> unique abbreviations)?
>>>> 1: User (U)
>>>> 2. Authorization Service (A)
>>>> 3. Responder Service (R)
>>>> 4. Client Service (C)
>>> I've been lurking at this discussion while trying to make a clear
>>> opinion, but now I must say I like this
>>> proposal: clean, clear and well aligned with IETF's OAuth...
> Eve Maler
> eve at xmlgrrl.com
> Wg-uma mailing list
> Wg-uma at kantarainitiative.org
More information about the Wg-uma