Whew, a response for the last message in this thread series. Hope y'all get
a chance to ponder and add your thoughts.
The biggest question is probably: How materially different are the UMA
definitions of entities, where OAuth has a version of same? Given our
alignment work, the delta has probably decreased, and that's good. To the
extent that we can be more precise about the delta, it helps make the case
for keeping the same name (where we decide that's what we want to do).
For (UMA) *resource owner (RO)*, the key distinction about our UMA
extension grant of OAuth is that it is asynchronous, such that it is not
the RO (using a client) who takes action to initiate the grant, it is an
autonomous entity (unless the entity in the latter role is also in the RO
role). Seems straightforward enough to explain, and motivate use of our
enhanced UMA version of the OAuth term.
We invented the phrase (UMA) *requesting party* (*RqP*); OAuth doesn't have
this. It is unique to UMA as an extension of OAuth because UMA enables
sharing with an autonomous entity, as explained above. The rationale for
having a new term is clear, but the term itself has caused some confusion.
I'm a bit troubled that it's the only term in the technical spec with
"party" in the name; that's a legal, not a technical, concept. A long time
ago, we used the word *requester* (for the "UMA client" role, but
still...). Is it helpful at all to think about a new name at this point?
We'd potentially have RO, RS, and R. Is that any better? Note that in the
legal realm, we've introduced Grantor and Grantee; the reason I'm not
suggesting those parallel terms here is because they represent only a
*subset* of the UMA-technical concepts, and there are more legal terms
coming...
We use (UMA) *client* (and colloquially, though not officially, abbreviate
it to *C*), and use the word exclusively for the client that the requesting
party uses. There are several reasons this has been confusing. One is that
both the (UMA) client and the (UMA) resource server are OAuth clients of
the (UMA) authorization server, with client creds and everything. Another
is that there are presumably dedicated client apps/user agents that give
the resource owner some sort of UX to her AS and her RS, but these are
entirely out of band of UMA. You can see this in the form of the "with any
user agent(s)" gray bar at the top of this diagram
http://kantarainitiative.org/confluence/download/attachments/17760302/uma-in....
I've been prefacing "client" with "UMA" or "OAuth" whenever there's a
chance of ambiguity. I think the Gluu folks like *relying party* for "UMA
client", but I fear that its use in identity-land might contribute to
confusion. Would *requesting client* (*RC*) or some such help?
The (UMA) *authorization server* (*AS*) is an enhanced version of an OAuth
one, but less enhanced than before. We've removed the RPT endpoint, and
explained fairly clearly (with more explanation to come) how to use/reuse
the token endpoint for Alice and then Bob. Does it work sufficiently as a
reused term?
The (UMA) *resource server* (*RS*) is an enhanced version of an OAuth one.
To become "UMA-protected" requires doing the RSR interface, being a client
of the whole protection API, and dealing with some new client-to-RS-first
stuff to support the overall authorization interface (and behind the
scenes, do stuff like map incoming API calls to the resource set IDs it's
been getting back from the AS). So the delta is non-trivial, but the
benefit of outsourcing protection to the AS is conceptually the same and a
lot of it can be packaged into an SDK or whatever in a similar way. Is the
existing name fair? I do think enumerating the comparison list will be
helpful.
I think it's really time to look at *resource set* vs. using *protected
resource* (which is what OAuth officially calls resources under OAuth
protection). We do already use the latter in a few places, along with
shortening it to just "resource" sometimes. Such a change would presumably
affect what we call "resource set IDs", and this would touch both specs,
but considering that a lot of the OAuth community already colloquially
talks about "PRs", that could be worth it. Thoughts?
As for *scopes*, we've done a bunch of alignment already to ensure that
scopes -- as used and defined by OAuth itself -- are accommodated by scope
description documents and such now. I think the word itself is fine. If
anyone knows of other cleanup we should do around this, just shout.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Tue, Nov 1, 2016 at 6:24 PM, Eve Maler
https://github.com/KantaraInitiative/wg-uma/issues/256
This is one of a series of messages meant for discussion of naming of entities and concepts. This message consolidates a bunch of *major entity/concept* terms from the GitHub issue:
- resource owner (RO) (original; from OAuth) - requesting party (RqP) (original; confusion with identity "RP") - resource server (RS) (enhanced OAuth version; also acts as OAuth client; confusion with identity "RP") - client (enhanced OAuth version; also acts as OAuth client; confusion with identity "RP") - authorization server (AS) (enhanced OAuth version) - resource set (original), protected resource, resource (colloquial) - scopes (also appeared in the *authorization/claims* message)
For now, let's please discuss only in email, unless we're all somehow magically aligned by the time we get to the next call. I'll provide my own thoughts in a followup message.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl