[Wg-uma] Terminology

Iain Henderson iain.henderson at mydex.org
Thu Aug 27 21:37:33 PDT 2009


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

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.







More information about the Wg-uma mailing list