** doesn't provide enough information to RPs (e.g. name, photo, etc.)
** 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"/>
