[WG-UMA] GitHub Issue #88 relating to RPT

Kathrynn Gonzalez katie.gonzalez at forgerock.com
Fri Aug 15 15:26:01 CDT 2014


Hello all,

I'd like to address issue #88 as the same topic continually arose in my
mind throughout our implementation of the UMA spec this summer.
Consider exposing RPT validity to client and allowing more AS control of it
#88
*The Issue states*:

"Maciej suggests that it would be handy for the AS simply to refresh an old
existing RPT, rather than invalidating an old one and handing out a new
one. The spec text is potentially too implementation-specific in dictating
token validity period handling. Did we mean to suggest that an old RPT and
all of its authorization data needs to be revoked when the client makes
this request? This is somewhat related to Maciej's additional suggestion
that perhaps the RPT could either contain in-band, or enable the client to
request through introspection, its own validity period. This would be at
most a hint that the RPT is still valid, because it could be invalidated at
any time. Currently the client only finds out that an RPT is no good when
it tries to use it and the RS responds appropriately to an invalid RPT."

---------------
I too questioned why just requesting a new resource would cause loss of all
previous authorization data. Dealing with the validity of the RPT seems to
be part of the question as to how the RPT gets handled at this point.
Following are some questions that I feel are helpful to ask and my input to
each. I would love to see some other ideas and feedback on this as well.


   - Is there any value to the RPT even having an expires_at?


~ I believe there is value to the expires_at if you envision the RO being
able to restrict/set or extend length of access rights to a CS/RP.


   - If there is value, is it a MUST that the RPT has an expires_at, or
   could it be optional?


~ I think the expires_at could be optional. I like the idea of keeping it
for the above purposes, but I don't really see the need on why it should be
a MUST. If the permissions themselves are associated with an expires_at
then it seems redundant to require the RPT to contain an expiration.
"Refreshing" could be considered a way of handling the RPT permissions
rather than in terms of a time frame, as addressed below.


   - To avoid loss of authorization data, could a possibility be to
   "refresh" the RPT by modifying permissions each time through addition of
   new permissions and deletion of expired permissions (opposed to thinking
   of  "refreshing" as a time period), Instead of "invalidating" the RPT and
   issuing a new one?


~ In my opinion the RPT should not have a required expires_at and should
have new permissions for the RPT associated with that RS (question of how
they tie to the RS is raised in issue #99) added to the current RPT through
a possible "refreshing" as above. How any "optional" expires_at
implementations deal with expiration can be outside the scope of the spec
and left as an implementation decision.
---------------

I hope these questions raise some thought and provoke discussion. I may not
be able to respond much for a week or two but hope some of the group can
get a conversation beginning amongst yourselves during that time in an
effort to resolve and close issue #88.


Katie Gonzalez
Intern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-uma/attachments/20140815/ad18bbe2/attachment-0001.html>


More information about the WG-UMA mailing list