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
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:
> Eve Maler schrieb:
>> Christian pointed me to the (fairly new) OAuth Authentication IETF
>> 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
>> 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 at xmlgrrl.com
More information about the Wg-uma