[Wg-uma] Terminology

Eve Maler eve at xmlgrrl.com
Tue Sep 1 14:43:06 PDT 2009

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'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  


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

More information about the Wg-uma mailing list