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
> # 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.
> On 27 Aug 2009, at 21:12, Eve Maler wrote:
>> Christian pointed me to the (fairly new) OAuth Authentication IETF spec:
>> 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
>> 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 Maler
>> eve at xmlgrrl.com
>> Wg-uma mailing list
>> Wg-uma at 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
More information about the Wg-uma