Completing this thread for now, Core rev 07 contains the final edits as discussed above and discussed/agreed in telecon 2016-11-10 (impacting rhetoric and syntax both). As soon as I get a chance (hopefully by telecon 2016-11-18), I'll also be able to complete the corresponding edits to RSR (will become "RR") rev 01.On Tue, Nov 8, 2016 at 12:15 PM, Adrian Gropper <agropper@healthurl.com> wrote:Not a moment too soon. This is still a point of confusion in this week's HEART call.Adrian
On Tuesday, November 8, 2016, Eve Maler <eve@xmlgrrl.com> wrote:I'm currently working on the "resource set" --> "(protected) resource" language switch. I'm going to do it in stages so we can decide if we want to keep the rhetorical switch without changing any syntax; the syntax changes affect both Core and RSR (endpoint name stuff and JSON properties).I can report that it feels really right to change this. Talking about resources, protecting resources, registering them for protection, etc. is natural. I've now got a definition of "protected resource" (was "resource set") that starts this way: "A digital resource to which a resource owner is able to control access grants. From the resource server's perspective, the resource might consist of one or multiple parts, but it is managed as a single resource from the perspective of UMA protection."On Sat, Nov 5, 2016 at 10:25 PM, Eve Maler <eve@xmlgrrl.com> wrote:Thanks for the feedback, Adrian. I plan to work on Core rev 07 and, as warranted, RSR rev 01 by Tuesday, and can attempt to implement the general sense of the proposals, or revised versions if there's feedback that suggests a different course. Keep those cards and letters coming!On Fri, Nov 4, 2016 at 2:57 PM, Adrian Gropper <agropper@healthurl.com> wrote:The only one I have feelings about is RqP. I've never had a problem with it. Shortening to requester would make it harder to explain the difference between UMA Client and the entity operating the UMA Client.In HIE of One, where we're just trying to duplicate the current user experience with state-level health information exchanges (HIE), the distinction between claims presented by a UMA Client such as a hospital and the claims presented by a staff member at the hospital is very important. It defines how discovery and invitations work in the real world. It brings in core issues of workflow, reliability, etc... that are never an issue with OAuth.I would keep RqP.AdrianOn Fri, Nov 4, 2016 at 2:57 PM, Eve Maler <eve@xmlgrrl.com> wrote:______________________________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. 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.On Tue, Nov 1, 2016 at 6:24 PM, Eve Maler <eve@xmlgrrl.com> wrote: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._________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma
--Adrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
--Adrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/