[WG-UMA] Discussion on Github Issue #99

Salvatore D'Agostino sal at idmachines.com
Fri Aug 15 19:00:40 CDT 2014


Oops wrong thread…

 

From: wg-uma-bounces at kantarainitiative.org [mailto:wg-uma-bounces at kantarainitiative.org] On Behalf Of Salvatore D'Agostino
Sent: Friday, August 15, 2014 7:13 PM
To: 'Casey Gilray'; WG-UMA at kantarainitiative.org
Subject: Re: [WG-UMA] Discussion on Github Issue #99

 

Fair enough,

 

I guess its now the AS

 

https://kantarainitiative.org/confluence/display/uma/Home 

 

so we want to use an AM/AS from the list where we put together identities and claims and  where the door controller is the resource server that enforces them and the client is the card/credential card reader interaction?

 

From: wg-uma-bounces at kantarainitiative.org [mailto:wg-uma-bounces at kantarainitiative.org] On Behalf Of Casey Gilray
Sent: Friday, August 15, 2014 4:06 PM
To: WG-UMA at kantarainitiative.org
Subject: [WG-UMA] Discussion on Github Issue #99

 

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> https://github.com/xmlgrrl/UMA-Specifications/issues/99

-- 

Casey Gilray

Intern in the CTO Office

Forgerock Vancouver

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-uma/attachments/20140815/8a08f5f3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6085 bytes
Desc: not available
URL: <http://kantarainitiative.org/pipermail/wg-uma/attachments/20140815/8a08f5f3/attachment-0001.bin>


More information about the WG-UMA mailing list