[Wg-uma] Terminology

Eve Maler eve at xmlgrrl.com
Mon Aug 31 18:15:20 PDT 2009

Glad to see some additional activity in this thread!

Christian makes a good point: entity #4 is sometimes just consuming a  
*response* from #3, but is perhaps writing data into #3, so Consumer  
is an inconvenient name.  I would add that -- Doc Searls's  
protestations to the contrary in VRM discussions -- "consumer" often  
refers to *people* on the web (e.g., "consumer identity" is discussed  
vs. B2B identity), so Consumer can lead to massive confusion between  
the true entity #4, which is a protocol endpoint, and a human being  
(sort of a phantom entity #5) who may be standing behind it.

I'm comfortable with the classic "User" for entity #1, even though  
this person is most emphatically not literally being a "user" at every  
given moment. :-)  I can see the logic of Iain's suggestion of Data  
Subject, but can I say that it sounds unnatural to my ear and seems to  
take away the "user-drivenness" that we're going for (by making the  
human seem like a passive party)?

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)

Note that Paul Trevithick had a blog post where he proposed four  
parties that are fairly closely aligned with ours (by design), but he  
came up with different terms for #3 and #4: Providing and Relying  
parties. I think this would work better if we weren't including read- 
write service access:


By the way, in early iterations of the ProtectServe work, we talked  
about #1 being a "publisher" and the (phantom) #5 party that stands  
behind #4, whether they're a natural person or a legal person  
(corporation), as being a "subscriber".  I still like this a lot,  
since #1 could eventually be a non-natural person too and it would be  
nice to get away from User -- BUT pub/sub language gets awkward for  
that read-write service access situation again.  Darn it.


On 31 Aug 2009, at 2:43 PM, Christian Scholz wrote:

> Hi!
> Eve Maler schrieb:
>> Christian pointed me to the (fairly new) OAuth Authentication IETF  
>> spec:
>> http://www.ietf.org/id/draft-ietf-oauth-authentication-01.txt
>> It uses "client, server, protected resource, token and resource  
>> owner" terms, harking back to HTTP authentication terms, which  
>> seems very appropriate.
>> So we have these names for "parties" as a backdrop (I hope the tabs  
>> get retained properly!):
>> Old OAuth:    User        (nothing)    Service Provider    Consumer
>> New OAuth:    Resource Owner    (nothing)    Server            Client
>> ProtectServe:    User        Authz Manager    Service Provider     
>> Consumer
>> UCAC:        User        Sec Provider    Web Application         
>> Consumer
>> UMA:        ?? (#1)        ?? (#2)        ?? (#3)            ?? (#4)
>> I have kept saying that we want to stick with OAuth terminology,  
>> but there are a couple of reasons that we may not want to:
>> - OAuth's growing association with low-level HTTP functions makes  
>> our UMA level seem much more in the "application stratosphere".
>> - Though an OAuth Server/Client relationship obtains between our AM  
>> and SP, it's admittedly confusing to reuse OAuth terms in their non- 
>> natural "positions".
> I just want to mention the following: Having too many termy is also  
> very confusing. It already confuses me. On the other hand while I  
> was at the beginning for using client and server I might have  
> changed my mind as we are probably a layer above OAuth. We should  
> make sure though that we always make it crystal clear in the spec  
> (and also outside of it) which party is the client and server in  
> OAuth terms in case OAuth is used.
> I would also encourage to use client/server when talking about OAuth  
> because otherwise it really gets confusing. Unfortunately though  
> there are multiple versions of the OAuth spec around, the IETF one  
> not being the official one yet.
>> If you buy this argument, then we probably want to strongly  
>> *distinguish* between our terms and OAuth's.  It would at least  
>> make it easier to talk about "UMA party #2 and UMA party #3 donning  
>> the OAuth Server and Client roles, respectively, so that #3 can  
>> make authorization decision requests of #2" etc.  I expect there to  
>> be other "applications of OAuth" besides our own, so perhaps we can  
>> lead by example.  Also, I know Paul would very much like the  
>> interactions in which our party #4 takes part to be a lot more  
>> OAuth-compliant than they are now, and I can only imagine the mess  
>> we'll get into if we try and explain our parties to folks on the  
>> OAuth list using superficially similar terms.
>> So, if you buy my argument and we can open up the term universe a  
>> bit more...  Anyone got suggestions for #1, #2, #3, and #4?   
>> ("User" might be okay to keep for #1 -- little chance of confusion.)
>> And finally, how can we refer to a web application that hosts a #2  
>> endpoint at minimum, but might also co-locate endpoints for #3 and  
>> even #4?  I've been calling this a "relationship manager", but this  
>> has been only a partial success at best.
> #1 User
> #2 Authorization Manager (or is it some sort of proxy?)
> As for #3 and #4 I am not sure.. Coming up with new terms is always  
> complicated ;-)
> Why can't we simply call #3 a "Service" btw? Do we group by provider  
> somewhere? and if is this important?
> As for #4 my brainstorming would be that consumer sounds a bit too  
> much like just reading.. It can also be writing though. But I am not  
> finding a term describing that so I keep that to the native language  
> people here.
> -- christian

Eve Maler
eve at xmlgrrl.com

More information about the Wg-uma mailing list