eve at xmlgrrl.com
Tue Sep 1 14:43:06 PDT 2009
Perhaps we're getting closer! If User as entity #1 gets consensus,
and "... Service" gets consensus, then we can get down to arguing
about the three instances" of "...".
Does Authorization Service work for entity #2?
Could we be happy with Client Service for entity #4? I'm finding
myself quite comfortable with it.
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
the 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
infrastructure 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
"relationship manager" problem too. Let me try out an alternative: an
"access manager" 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
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
> "services" 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.
> All 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
> and 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 at xmlgrrl.com
More information about the Wg-uma