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

Maciej Machulak maciej.machulak at gmail.com
Tue Aug 26 17:11:15 CDT 2014


As I see right now, it's actually related to GitHub Issue #88 (sent earlier
to the list) so maybe this can be discussed as part of that particular
issue.


On 26 August 2014 22:14, Maciej Machulak <maciej.machulak at gmail.com> wrote:

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



-- 
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/e3fefdea/attachment.html>


More information about the WG-UMA mailing list