[Wg-uma] Terminology

Christian Scholz cs at comlounge.net
Mon Aug 31 14:45:39 PDT 2009

Iain Henderson schrieb:
> How about the following
> # 1  Data Subject (or Individual). These terms are embedded in privacy 
> legislation worldwide, and thus offer a solid platform on which to 
> build that extends far beyond technical specs in ways that I think 
> will prove very helpful in deployment. Of the two, I think Individual 
> is spread more widely in legislation, but Data Subject is more 
> descriptive in our context so i'd go with that.
> # 2  Relationship Manager. In VRM world we have done a lot of work on 
> the concept and practicalities relationship management (in the 
> customer/ supplier context) and there is clearly a need for 
> capabilities to be built in that space; so provided we are very clear 
> about what this capability does then it is a good term.
> # 3  Service Provider. I think this is broader/ more inclusive than 
> the others and offers the option to not be specific to web based 
> applications.
> # 4  Data Consumer. Consumer on its own is a horrible term with 
> multiple misinterpretations, but Data Consumer is a very clear 
> articulation of the role being performed #4
But it's not really just consuming data, it can also write data (think 
activity streams). So I am more or less against consumer but I am not 
sure what the feel for native speakers is regarding this word.

-- christian

> Iain
> On 27 Aug 2009, at 21:12, Eve Maler wrote:
>> 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".
>> 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.
>>     Eve
>> 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 
> Iain Henderson
> iain.henderson at mydex.org
> This email and any attachment contains information which is private 
> and confidential and is intended for the addressee only. If you are 
> not an addressee, you are not authorised to read, copy or use the 
> e-mail or any attachment. If you have received this e-mail in error, 
> please notify the sender by return e-mail and then destroy it.
> _______________________________________________
> Wg-uma mailing list
> Wg-uma at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma_kantarainitiative.org 

More information about the Wg-uma mailing list