Great comments; thanks to Christian for responding. To answer just a couple of more points that I don't think got addressed yet:
Yes, we would very much like for dynamic client registration to become a work item of this group. (Do we need to take any steps other than stating so in this email?) And, I've written to this list a couple of times in the past, describing ways in which UMA builds on top of OAuth (it's basically a series of profiles and extensions, any of which I'm willing to believe might have value to a wider community on its own), but it seems like a summary at this juncture would be a good idea. If OAuth has two steps, "get a token" and "use a token", UMA has three, adding one at the beginning: - Step 1: trust a token: Authorizing user introduces host to authorization manager as an OAuth client of it. The host and AM need to acquaint themselves with each other in the context of this user to support the user's setting of policies at the AM that will govern the giving out of requester access tokens for the host's protected resources later. The specifics involve the host actually getting its own access token that it can use at a host-specific set of endpoints at the AM (it's basically an embedded instance of OAuth). As necessary, the dynamic client registration stuff comes in. - Step 2: get a token: The requester approaches a protected resource, learns where to go to get an access token, and sets about trying to get it in mostly a normal fashion (engaging in dynamic client registration as necessary). What UMA adds on top is that the AM can ask the requester to produce "claims" in support of proving its suitability for getting the token. If the authorizing user had set policies that could be applied unilaterally in token issuance, great, but if the user had set policies that require the requester to (say) promise to adhere to the user's licensing terms, that can be provided in a claim. (The mechanism is simple so far, but the implications are powerful... We've been exploring legal considerations of authorizing access by fully autonomous parties.) - Step 3: use a token: Requester wields token at host to get access. What UMA adds on top is the host's ability to talk to the AM on a back channel to validate that token, to support minimal host implementations and fully dynamic host deployments. We're still in the process of defining (and in some cases redefining) the various protocol bits, and welcome input and engagement from others if the use cases we're solving for float your boat. If you want to see a full experimental implementation (soon to be open-sourced, I understand) in action, I-D coauthor Maciej and his crew are documenting their work at http://smartjisc.wordpress.com/. Eve On 11 Aug 2010, at 3:40 AM, Torsten Lodderstedt wrote: > Eve, > > thank you for writting this document. I consider it a good starting point for > a discussion about client registration and discovery. Will you propose this > as a WG item? > > My comments & questions: > > You propose a host-meta based discovery of the registration endpoint on the > authz server. Could this mechanism be used for discovering all AS endpoints, > e.g. tokens and end-user authorization? > > How is a UMA requestor envisioned to discover the auth server? > > I think host-meta based client discovery could be to limited since it does > not allow (at least in my understanding) to serve different clients (or their > home web apps) on the same host. What about using JRD or XRD? This would > allow for a client-URL-related discovery. > > What means for authentication a client against its home web app. do you > envision? > > regards, > Torsten. > > Am 10.08.2010 um 21:31 schrieb Eve Maler <e...@xmlgrrl.com>: > >> Folks-- The UMA group has produced the following I-D as input to the OAuth >> discovery/registration/binding discussion. We wanted to set forth our >> requirements (knowing that there may be other requirements from the wider >> community) and propose some solutions that meet them. If further discussion >> seems to warrant an updating of this draft, we're happy to do that. (If you >> have interest in getting involved in UMA-specific work, feel free to drop me >> a note.) >> >> Eve >> >> http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt >> >> Begin forwarded message: >> >>> From: IETF I-D Submission Tool <idsubmiss...@ietf.org> >>> Date: 10 August 2010 12:23:59 PM PDT >>> To: e...@xmlgrrl.com >>> Cc: c...@comlounge.net, m.p.machu...@ncl.ac.uk >>> Subject: New Version Notification for draft-oauth-dyn-reg-v1-00 >>> >>> >>> A new version of I-D, draft-oauth-dyn-reg-v1-00.txt has been successfully >>> submitted by Eve Maler and posted to the IETF repository. >>> >>> Filename: draft-oauth-dyn-reg-v1 >>> Revision: 00 >>> Title: OAuth Dynamic Client Registration Protocol >>> Creation_date: 2010-08-10 >>> WG ID: Independent Submission >>> Number_of_pages: 20 >>> >>> Abstract: >>> This specification proposes an OAuth Dynamic Client Registration >>> protocol. >>> >>> >>> >>> The IETF Secretariat. >>> >>> > Eve Maler http://www.xmlgrrl.com/blog http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
