[Wg-uma] Terminology

Eve Maler eve at xmlgrrl.com
Thu Sep 3 07:11:08 PDT 2009

Definitely worth discussing today.  If 3 x "Service" is more confusing  
than helpful, we can perhaps go with a single-word name -- like  
Madonna, Rihanna, and Prince :-), or more seriously, like User,  
Authorizer, Host, and Client.

Regarding pub/sub, in the past we had used these words to refer to the  
*person* (natural or legal) behind the offer of the terms (entity #1),  
and the *person* (natural or legal) behind the acceptance of the terms  
(starting to be a phantom entity #5!), with the authz service (entity  
#2) being the first one's agent on the web and the consumer/client  
service (entity #4) being the other one's agent on the web.  So I  
don't think it's the same thing as subscribing to an API, and in any  
case we've got two parties (entities #3 and #4) who sort of subscribe  
to APIs...  Pub/sub felt pretty natural at the time because we were  
focusing on one-way data-sharing a la "feed-based VRM", but opening up  
the scope to any service access a la OAuth may make these terms a bit  
too narrow


On Sep 1, 2009, at 3:17 PM, Christian Scholz wrote:

> 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 it ;-)
> 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).
> -- Christian
>> 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).
>> Eve
>> 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
>>> interactivity.
>>> 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:
>>>> Hi,
>>>> 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
>> 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

More information about the Wg-uma mailing list