[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

	Eve

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
http://www.xmlgrrl.com/blog




More information about the Wg-uma mailing list