Issue #256: Consider the naming of entities and concepts: major entity/concept terms

newer
Applicability of OAuth 2.0 hack to...

older
Token profiling and requiring the...

Eve Maler

1 Nov 2016 1 Nov '16

9:24 p.m.

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

Attachments:

attachment.html (text/html — 1.9 KB)

Show replies by date

Eve Maler

4 Nov 4 Nov

2:57 p.m.

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 wrote:

...

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

Adrian Gropper

5:57 p.m.

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. Adrian On Fri, Nov 4, 2016 at 2:57 PM, Eve Maler 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 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 wrote:

...
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

_______________________________________________ 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/

Eve Maler

6 Nov 6 Nov

1:25 a.m.

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! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Fri, Nov 4, 2016 at 2:57 PM, Adrian Gropper 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.

Adrian

On Fri, Nov 4, 2016 at 2:57 PM, Eve Maler 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 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 wrote:

...
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

_______________________________________________ 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/

Eve Maler

8 Nov 8 Nov

1:48 p.m.

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."* *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Sat, Nov 5, 2016 at 10:25 PM, Eve Maler 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!

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Fri, Nov 4, 2016 at 2:57 PM, Adrian Gropper 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.

Adrian

On Fri, Nov 4, 2016 at 2:57 PM, Eve Maler 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 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 wrote:

...
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

_______________________________________________ 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

3:15 p.m.

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 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."*

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Sat, Nov 5, 2016 at 10:25 PM, Eve Maler javascript:_e(%7B%7D,'cvml','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!

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Fri, Nov 4, 2016 at 2:57 PM, Adrian Gropper javascript:_e(%7B%7D,'cvml','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.

Adrian

On Fri, Nov 4, 2016 at 2:57 PM, Eve Maler javascript:_e(%7B%7D,'cvml','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 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 javascript:_e(%7B%7D,'cvml','eve@xmlgrrl.com');> wrote:

...
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

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org javascript:_e(%7B%7D,'cvml','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/

Eve Maler

11 Nov 11 Nov

3:45 p.m.

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. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Tue, Nov 8, 2016 at 12:15 PM, Adrian Gropper 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 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."*

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Sat, Nov 5, 2016 at 10:25 PM, Eve Maler 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!

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Fri, Nov 4, 2016 at 2:57 PM, Adrian Gropper 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.

Adrian

On Fri, Nov 4, 2016 at 2:57 PM, Eve Maler 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 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 wrote:

...
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

_______________________________________________ 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/

Eve Maler

4:05 p.m.

Actually, maybe not quite complete. I wanted to bring up the topic of UMA vs. OAuth "client" for potential discussion. With the relationship of the UMA spec to OAuth greatly clarified, I wonder if we need not distinguish "UMA vs. OAuth" versions of the major entities anymore, except to the extent of adding the requesting party. The role of a client in UMA is *to be used by a requesting party*, and *a resource server and an authorization server can be loosely coupled, to be joined in the context of a resource owner*, but otherwise there's a lot that's the same. We've explicitly added a) a Resource (Set) Registration API, b) an authorization interface, and c) an UMA grant inside that authorization interface precisely to dictate how these additions become interoperable. We could base our Introduction on an explanation that runs like this, and we could base our Terminology section more firmly on the OAuth definitions. We could potentially eliminate some of the definitions that are in there. I'm envisioning a new, very high-level comparison diagram showing these additions (am I missing any?) in the Intro, followed by Dom's new spiral-based diagram (ASCIIfied somehow) for the high-level flow. Then in Sec 3's intro, which I have to totally redo, we can put the more flowchart-style diagram. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Fri, Nov 11, 2016 at 12:45 PM, Eve Maler wrote:

...

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.

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Tue, Nov 8, 2016 at 12:15 PM, Adrian Gropper 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 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."*

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Sat, Nov 5, 2016 at 10:25 PM, Eve Maler 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!

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Fri, Nov 4, 2016 at 2:57 PM, Adrian Gropper 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.

Adrian

On Fri, Nov 4, 2016 at 2:57 PM, Eve Maler 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 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 wrote:

> 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 > >

_______________________________________________ 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/

2869

Age (days ago)

2878

Last active (days ago)

List overview

Download

7 comments

2 participants

participants (2)

Adrian Gropper
Eve Maler

Issue #256: Consider the naming of entities and concepts: major entity/concept terms

tags

participants (2)