Hi Farazath— BTW, congratulations on completing your GSoC project!Officially, the RS outsources all aspects of protection to the AS, so it doesn’t “recognize” clients in any in-band UMA way. E.g., it doesn’t see their client ID.However, it’s free to use any contextual methods that it wants for observing and acting on requests for access. In fact, hmmm. Given the last couple of tweaks we just made to the specs in V1.0.1, where it’s not just “403 recommended and you’re on your own for any other status codes”, but “the RS can produce any status codes it wants as long as it uses the UMA header when it’s doing UMA”, you could theoretically add “preprocessing” and “postprocessing” trust elevation flows that are RS-specific.(The user experience might get more and more horrible, though, depending on what impact it has on the requesting party. That’s for your authentication strategy to decide.)EveOn 31 Aug 2015, at 3:12 AM, Farazath Ahamed <mefarazath@gmail.com> wrote:_______________________________________________Hi,First of all thanks everyone for helping me out in this mailing list answering my questions that helped me a lot in getting through my GSoC. However, I am yet to complete my implementation. Therefore i will keep on pestering you with questions :)Getting to the question,We use the PAT to register permissions using the Permission Registration endpoint of the Protection API, do we have a standard way of associating the client who requests for access from the UMA protected resource server?Thanks--A.Farasath AhamedUndergraduate | Department of Computer Science and Engineering,University of MoratuwaArticle Writer | MoraSpiritMobile: +94 777 603 866E-Mail: mefarazath@gmail.com
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma