[WG-UMA] Discussion on Github Issue #99

Maciej Machulak maciej.machulak at gmail.com
Tue Aug 26 15:16:00 CDT 2014

Hi Eve,

I would add these comments:

> *Option 1: keep current "long flow"*
> Pros: doesn't ask RS and AS to perform work until C has done some work;
> backwards compatible (= identical) with V0.9 behavior
> Cons: more multi-party HTTP interactions just to get access the first time

Just to bear in mind that the above con is "weak" as the RPT has to be
obtained only once per RS. Therefore, some may consider this interaction

> *Option 2: switch to "short flow"*
> Pros: shortens the number of HTTP interactions that lead to access
> Cons: C could force RS to do a lot of work getting permission tickets in
> DoS fashion; backwards incompatible with V0.9 behavior
> *Option 3: let the RS freely choose which flow to use*
> Pros: lets the RS assess context, trust relationships, etc. (could do it
> once but refuse a second time on seeing the same C) and still requires
> simple deterministic behavior from the C: if no ticket, get RPT and retry;
> backwards compatible with V0.9 behavior
> Cons: introduces optionality into the spec

And also requires the client to be prepared to implement additional logic.

> Eve


> On 15 Aug 2014, at 1:06 PM, Casey Gilray <casey.gilray at forgerock.com>
> wrote:
> As issue #99 stands now there is an open question as to whether it would
> be better to automatically send a ticket along with an RPT to the clients
> instead of forcing them to request a ticket separately. Currently the
> client must request a resource from the RS and be sent an error requesting
> that the client get an RPT. The client obtains the RPT and tries the
> request again in order gain a permission ticket. The proposed work around
> is for the RS to obtain the RPT and automatically register the sought
> permissions, then return the new RPT along with the permissions ticket.
> There are valid reasons to have both paths available. Issuing the ticket
> automatically may tie up more resources on the server side but this also
> frees the client from making several requests. This leaves the server more
> vulnerable to denial of service attacks at this endpoint. If you are not a
> high value target for DDoS or are otherwise not worried about attacks then
> having the server automatically issue the ticket along with the RPT would
> be a valid solution.
> The second part of issue #99 deals with the binding between an RPT and the
> RS. When a client obtains an RPT there is no notion of which RS this RPT
> will be used with. It was suggested that the Client pass a host ID, a
> identifying token which is known by the AS. These hostID tokens could be
> stored dynamically or have static “trusted” host IDs depending on the
> security demands of the implementation.
> In an attempt to open discussion to close issue #99 I will pose the
> following question: Would it be possible to add into the spec the option
> for the RS to either obtain and create tickets for requests automatically
> or make the client obtain and re-request with a new RPT OR, leave the spec
> as is where the client is forced to obtain their RPT from the AS, then
> attempt the request again to get the permissions ticket.
> Secondly, In regards to binding could the RPT request include a host_id
> parameter that could match to a list of known and trusted RS’s, thus
> binding each RPT to one specific RS?
> Link to issue #99: https://github.com/xmlgrrl/UMA-Specifications/issues/99
> Eve Maler                                  http://www.xmlgrrl.com/blog
> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
> _______________________________________________
> WG-UMA mailing list
> WG-UMA at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma

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

More information about the WG-UMA mailing list