This is the description of the protocol flow I use in my prototype at http://host.clproject.net/
General notes
- Instead of XRD I use a slightly modified variant of JRD as it is simpler to parse.
- The Host contains three resources of Bob: a basic, a medium and a detailed profile.
- The only access conditition right now is a check on the username the requesting party provides at the AM. This could be an OpenID login in a real world scenario.
- many things are just inventions of my own where I thought it might work that way. These need discussion and proper specification.
Step 1: Introduction of Host to the AM
Step 1 starts when the user enters the location of the AM to be used for.
1.1: Obtaining the AM metadata
In order to start the process the Host needs to know various URI endpoints of the AM. These are retrieved by a hostmeta lookup by the Host (here is the live AM hostmeta). Technically it's a GET on the hostmeta URL and this is what it returns:
{ "property": [ { "http://uma/am/title": "Cop Monkey" } ], "expires": "2011-01-30T09:30:00Z", "link": { "http://uma/host/token_uri": [ { "href": "http://am.clprojects.net/host/token" } ], "http://uma/host/user_uri": [ { "href": "http://am.clprojects.net/host/authorize" } ], "http://uma/host/resources": [ { "href": "http://am.clprojects.net/host/resources" } ], "http://uma/requester/user_uri": [ { "href": "http://am.clprojects.net/requester/authorize" } ], "http://uma/requester/token_uri": [ { "href": "http://am.clprojects.net/requester/token" } ] }, "subject": "http://am.clprojects.net/" }
We see various endpoints here:
- a OAuth 2.0 user_uri endpoint for the Host to use (http://uma/host/user_uri)
- a OAuth 2.0 token_uri endpoint for the Host to use (http://uma/host/token_uri)
- a OAuth 2.0 user_uri endpoint for the Requester to use (http://uma/requester/user_uri)
- a OAuth 2.0 token_uri endpoint for the Requester to use (http://uma/requester/token_uri)
- a UMA resource registration endpoint (http://uma/host/resources). This is my invention
The Host stores all these endpoints for later usage.
1.2: Host registers Bob's resources at the AM and obtains client_id
In order for the AM to be able to manage Bob's resources it needs to know what these resources are. Instead of entering the URIs of them manually I invented some registration step to do so automatically.
For this the Host crafts a JRD document containing the resources identified by their resource URI and a title. The example in the prototype looks as follows:
{ "subject" : "http://host.clprojects.net/profiles/bob", # we copied this from the hostmeta JRD so we can skip one lookup here "property": [ { "http://uma/host/title" : "UMA Example Host" }, ], "link" : { # our namespace defining a protected resource "http://uma/am/resource" : [ # we have three protected resources as links { 'href' : 'http://host.clprojects.net/profiles/bob.basic', 'title' : 'Basic Profile', }, { 'href' : 'http://host.clprojects.net/profiles/bob.medium', 'title' : 'Medium Profile', }, { 'href' : 'http://host.clprojects.net/profiles/bob.detail', 'title' : 'Detailed Profile', }, ] } }
This document is sent to the http://uma/host/resources
endpoint of the AM which we retrieved via the hostmeta lookup. This is done via a POST request.
The AM then stores this information and assigns it a client_id
which then is returned to the Host. This is done in the response of the POST request. The document is JSON formatted and looks liks this:
{ 'client_id' : '622f5656-7211-4315-a69f-24fde3d65732', }
Now the AM knows about the resources of the Host and the Host has a client_id