[WG-UMA] Suggestion: improve text in Section 3.4.1

Maciej Machulak maciej.machulak at gmail.com
Tue Aug 26 16:14:07 CDT 2014


Hi,

A minor comment to potentially improve text in Section 3.4.1 where the
first paragraph currently reads as following:

   The client might need an RPT if it has never before requested an RPT
   for this combination of requesting party, resource server, and
   authorization server, or if it has lost control of a previously
   issued RPT and needs a refreshed one.  It obtains an RPT by using the
   authorization API, performing a POST on the RPT endpoint and
   supplying its AAT in the header.  No body is expected; if a body is
   present, the authorization server MAY ignore it.


The RPT currently is not bound to the RS when it is first requested but the
above text suggests that it is the case (possibly?).

Further, the text is as following:

   If the AAT provided in the header is the same as one provided for a
   previously issued still-valid RPT by this authorization server, the
   authorization server invalidates the old RPT and issues a new one.

   On first issuance, the RPT is associated with no authorization data
   and thus does not convey any authorizations for access.


I am not a native speaker but the above is ambiguous to me. If the RPT
existed and was invalidated and a new RPT was issued, does this new RPT
contain permissions of the previous RPT? Probably not; hence the following
text could possibly be improved:

   On first issuance, the RPT is associated with no authorization data
   and thus does not convey any authorizations for access.


I.e. maybe we could substitute "on first issuance [...]" with saying that
any RPTs that are returned to the client by this endpoint are not
associated with any authorisation data.

Furthermore, if we decide to introduce functionality where the RPT is bound
to the RS because the client supplied the host_id parameter in the request
to this endpoint, then we should consider extending this section and
introducing error codes/messages. Would there be use cases where the AS
could decide that the client cannot get an RPT for a particular RS based on
defined policies?

Please let me know your comments, thanks!

Cheers,
Maciej

-- 
Maciej Machulak
email: maciej.machulak at gmail.com
mobile: +44 7999 606 767 (UK)
mobile: +48 602 45 31 66 (PL)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-uma/attachments/20140826/a022e008/attachment.html>


More information about the WG-UMA mailing list