Confirmed users
1,021
edits
CloudServices/Roadmaps/Identity: Difference between revisions
CloudServices/Roadmaps/Identity (view source)
Revision as of 00:34, 4 February 2011
, 4 February 2011→Other Notes / Whiteboards
| Line 364: | Line 364: | ||
** doesn't provide enough information to RPs (e.g. name, photo, etc.) | ** doesn't provide enough information to RPs (e.g. name, photo, etc.) | ||
** confusing (I'm a URL?) | ** confusing (I'm a URL?) | ||
; OpenID vs. Identity Server | |||
The following outlines a simplified data transfer between two OpenID parties. | |||
It's a bit odd, and the terminology doesn't really seem to help. Here's my understanding of the total OpenID 2 flow (which might explain some of my confusion): | |||
1. Initiation & Normalization: | |||
User enters personalized OP URL into RP's identity form. (e.g. http://example.com/foo) which is normalized to a standard URL. | |||
2. Discovery: | |||
RP polls http://example.com/foo and finds the OpenID access point declarations: | |||
openid2.provider => endpoint url for OP | |||
openid2.local_id => local /claimed id (for us, it's the unique user+site id hash) | |||
3. Association: | |||
RP polls the openid2.provider passing: | |||
openid.ns = http://specs.openid.net/auth/2.0 | |||
openid.mode = associate | |||
openid.assoc_type = HMAC_SHA1 (or others) | |||
openid.session_type = DH_SHA1 (or others) | |||
OP responds with: (_this is where our JS library would start_) | |||
ns = http://specs.openid.net/auth/2.0 | |||
assoc_handle=255 char or less random string | |||
session_type = Association::openid.session_type | |||
assoc_type = Association::openid.assoc_type | |||
expires_in = {expiration time in seconds} | |||
RP replies with: | |||
openid.ns = http://specs.openid.net/auth/2.0 | |||
openid.mode = checkid_(immediate|setup) | |||
openid.claimed_id = Discovery::openid2.local_id | |||
openid.identity = OP provided local identifier value | |||
openid.assoc_handle = Association.response::assoc_handle | |||
openid.return_to = next URL to respond to | |||
openid.realm = Security realm for request (or return_to) | |||
and OP returns to the openid.return_to | |||
openid.ns = http://specs.openid.net/auth/2.0 | |||
openid.mode = id_res | |||
openid.op_endpoint = Discovery::openid2.provider | |||
openid.claimed_id = Association.request::openid.claimed_id | |||
openid.identity = Association.request::openid.identity | |||
openid.return_to = Association.request::openid.return_to | |||
openid.response_nonce = nonce | |||
openid.assoc_handle = Association.response::assoc_handle | |||
openid.signed = list of fields used to generate the signature | |||
openid.sig = signature | |||
We *could* add in the additional user information (like email, etc) into the final association response, since the protocol does allow for it, but we do run the risk of bumping up against max URL length issues with some systems. | |||
Things are a bit fuzzy for mew around the reuse of the association_handle values, and technically, we probably want to do the OpenID2 failure response for checkid_immediate (since we'd be requesting user interaction) but we might be able to skirt that as well. | |||
The additional step to all this is that there is an additional call back to the REAL RP where we pass along the information regarding the blessed user. There are some crypto concerns with Problematic Identity Transfer Agents (PITA) and getting a proper association handle defined. | |||
<br clear="all"/> | <br clear="all"/> | ||