eve at xmlgrrl.com
Thu Sep 3 07:11:08 PDT 2009
Definitely worth discussing today. If 3 x "Service" is more confusing
than helpful, we can perhaps go with a single-word name -- like
Madonna, Rihanna, and Prince :-), or more seriously, like User,
Authorizer, Host, and Client.
Regarding pub/sub, in the past we had used these words to refer to the
*person* (natural or legal) behind the offer of the terms (entity #1),
and the *person* (natural or legal) behind the acceptance of the terms
(starting to be a phantom entity #5!), with the authz service (entity
#2) being the first one's agent on the web and the consumer/client
service (entity #4) being the other one's agent on the web. So I
don't think it's the same thing as subscribing to an API, and in any
case we've got two parties (entities #3 and #4) who sort of subscribe
to APIs... Pub/sub felt pretty natural at the time because we were
focusing on one-way data-sharing a la "feed-based VRM", but opening up
the scope to any service access a la OAuth may make these terms a bit
On Sep 1, 2009, at 3:17 PM, Christian Scholz wrote:
> Am 01.09.2009 23:43, schrieb Eve Maler:
>> Perhaps we're getting closer! If User as entity #1 gets consensus,
>> "... Service" gets consensus, then we can get down to arguing about
>> three instances" of "...".
>> Does Authorization Service work for entity #2?
>> Could we be happy with Client Service for entity #4? I'm finding
>> quite comfortable with it.
> I sorta find the word a bit confusing because they all have
> "Service" in it ;-)
> Why is publisher and subscriber bad btw? Isn't one service
> subscribing to an API of another service which publishes that API?
> They even have some sort of contract eventually.
> And as I said before, I find everything related with "Storage"
> problematic because it might not be a storage but e.g. an API which
> opens some door or so (so here also "Data" would be problematic).
> -- Christian
>> I'm starting to like "Hosting Service" for entity #3, since a client
>> service that posts data into a hosting service is simply doing as the
>> user bids -- storing some data in (one of) their chosen host(s).
>> Using a
>> straight OAuth example to test the read-write situation, let's say
>> location service Dopplr is acting as an OAuth Client to FireEagle's
>> OAuth Server. We may also have an UMA Authz Service that mediates
>> whether Dopplr as an UMA Client Service can add location data to
>> FireEagle as an UMA Hosting Service. Not bad, I'd say.
>> I'm wary of "Data" because I'm hoping we can use the same
>> for "data" (small fields, identity attributes, etc.) and "content"
>> (user-generated content, photos, etc.). Not that these are pure or
>> well-defined terms, but I'd love to be inclusive.
>> (I'd be wary of "Storage", should anyone suggest it, since it would
>> sound like "storage as a service" cloud offerings...)
>> By the way, the repetition of "Service" may help with the
>> manager" problem too. Let me try out an alternative: an "access
>> could offer several "services": it offers an authorization service
>> at a
>> minimum, but it might also offer a hosting service (for personal data
>> not hosted elsewhere) and a client service (for keeping track of the
>> user's agreements to access the data of others).
>> On 1 Sep 2009, at 1:12 AM, Joe Andrieu wrote:
>>> This is getting close.
>>> I like User, especially as it is in sync with both UMA and UD-VPI
>>> I also like all of the other components as "services". The Client
>>> Service term might be improved, but I think it clarifies that the we
>>> don't mean the client software (user-agent) or a more traditional
>>> client in a client/server sense. Most importantly, I think
>>> as a common referent in 2,3, and 4, distinguishes them from the live
>>> person of the user.
>>> However, I think #3 "responder service" doesn't quite capture the
>>> essence. That service isn't defined by the fact that it responds.
>>> interactive services do respond to input. It's the nature of
>>> Rather, I think the #3 service as more of a data host or data
>>> provider. It is where the data lives that is being authorized for
>>> accessed through UMA. It is the source of the shared information.
>>> My own jargon would suggest "Datastore Service", but that may be too
>>> jargony. =)
>>> How about Data Service? Or Data Hosting Service? Or Hosting Service?
>>> On 9/1/2009 12:35 AM, Diego R. Lopez wrote:
>>>> On 1 Sep 2009, at 03:15, Eve Maler wrote:
>>>>> 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)
>>>> I've been lurking at this discussion while trying to make a clear
>>>> opinion, but now I must say I like this
>>>> proposal: clean, clear and well aligned with IETF's OAuth...
>> Eve Maler
>> eve at xmlgrrl.com
>> Wg-uma mailing list
>> Wg-uma at kantarainitiative.org
eve at xmlgrrl.com
More information about the Wg-uma