In the w3c webid project one of things we did with the folks at openlink was bridge a webid login (to an openlink server) to an openid service provider. Some CA issued a X.509 client cert with the webid URL as the name, and the openlink server verified the SSL assertion supported by said client cert. IT did so in response to receiving from an OpenID Consumer (SP) a request to challenge the user – which it duly did by invoking the webid challenge. Upon satisfaction of the webid challenge, the openlink server prepared an openid assertion for the requesting site – taking information from the user’s webid-associated foaf card.
In the latest experiment with bridging, we want to play more with oauth and openid and persona. Assuming that a chain of IDPs does much the same duty as the w3c experiment reported above, our goals is to deliver a signed JSON token to the SP website. Said website will then issue a .p12 credential to the iphone UA, bearing a webid-named X.509 client cert. That is, the website will authenticate the user, acting as an IDP relying upon the signed json assertion from Persona (as supported upstream by who knows how many IDPs). The site will bind the persona assertion to a local account; and then issue a local credential (a webid-enabled client cert). In short, its yet another IDP proxy in the chain, no different to what we discuss next -for an openid to oauth IDP proxy:-
Having installed the DISO openid plugin to wordpress and configured it so that registering users (for subscriber role, only) may create accounts automatically upon merely presenting a (verified) openid, we used the service ourselves.
Vreating an account on the local (or hosted version of) the wordpress site is easy – if all you want to be is a subscriber now with the power to issue OAUTH tokens! So, first create an account on my site:-
https://yorkporc.azurewebsites.net/wp-login.php and type myopenid.com in the openid login box!
Assuming you leverage your myopenid account (or create one) and have asserted back to my site, you are presented with your profile editing screen. You have formally logged in by this point, having received an automatically created subscriber-grade account).
So, from a challenge by openid…
we land with a shiny new subscriber-grade account on
Using the subscriber-available OAUTH provider console, note we have issued (as new user) NO access tokens to any OAUTH consumers. Access tokens are “per wordpress account”, that is. This makes perfect sense… since the application is speaking for this very same user (only).
From this position, what is the possibility that ANY OAUTH consumer can now seek to “authorize” an application – administered not by the subscriber but by the site’s administrator – against this new user?
Peter's ruminations 