In the recent thread here: http://www.ietf.org/mail-archive/web/oauth/current/msg01234.html Subject: "Recent UMA work that may inform this group's deliberations"
...Dick and I had a bit of discussion around UMA's proposal for a back-channel method of token validation that a Protected Resource could use at an Authorization Server. (In UMA terms, it would be a Host->Authorization Manager interaction, and indeed if this channel is inappropriate for core OAuth 2.0, UMA might define it as a separate subordinate protocol.) At the UMA F2F held Wednesday, we discussed this proposition in some detail, and continued to find the back channel interesting in our loosely coupled environment. Below I have reproduced the portion of meeting notes (from http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2010-03-10 ) where we discussed this. I hope it's useful/interesting. Eve ==== Back channel for token validation: Our "token validation URL" proposal is just a strawman. There are quite a few motivations for wanting this back channel, though: It allows for building a very lightweight host that can do token validation at request-time. The AM is the best entity to judge the token's suitability. Once this channel is enabled, the host can use it send audit log data to the AM for more interesting analytics. Or the AM could (at leisure after step 1 is done) dynamically provision the host with the ability to do local token validation (which ends up looking like a hybrid remote/local means of validation). Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
