OpenID Attribute Exchange Protocol questions

James Henstridge james at jamesh.id.au
Fri Jul 6 07:37:33 UTC 2007


On 06/07/07, Johnny Bufu <johnny at sxip.com> wrote:
> Hi James!
>
> On 4-Jul-07, at 9:05 PM, James Henstridge wrote:
> > 1. I noticed a few typos in the examples.  In section 5.1, it gives an
> > example of a fetch_request request reading:
> >
> >     openid.ns.ax=http://openid.net/srv/ax/1.0
> >     openid.ns.ax=fetch_request
> >     ...
>
> This would be a copy / paste error on my part; thanks for finding it!
> It's fixed now.
>
> > 2. The spec seems to omit details of how messages should be sent to
> > openid.ax.update_url.  In particular:
>
> Draft 5 is a bit old; there was also a draft 6 that never made it to
> the index page on openid.net.
>
> The latest revision in svn [1]  should be tagged as draft-7 any time
> now. Please have a look at it and see if there are still issues with
> the update mechanism (or anything else for that matter).

Okay, the new draft is clearer.

My question about the transaction ID in the update URL still stands:
won't a positive assertion response include openid.identifier and
openid.claimed_id, which should be enough for the RP to match up the
response?  Or do you expect the OP to not record the claimed
identifier from the original authentication request?

I think my question about what association handle to use for the
unsolicited response is adequately covered by the rules in section
11.4 of the OpenID Authentication spec: the OP could choose to use the
association from the original authentication request (if it is still
valid), or create a new private association handle.  In either case,
it should be ready to answer a check_authentication request.

My last question about indicating removed data still stands.  Consider
the following example:

1. The RP requests my phone and fax numbers in an OpenID authentication request:
    openid.ns.ax=http://openid.net/srv/ax/1.0
    openid.ax.mode=fetch_request
    openid.ax.type.phone=http://example.com/phone
    openid.ax.type.fax=http://example.com/fax
    openid.ax.required=phone,fax
    openid.ax.update_url=http://relying-party/...

2. My OP provides the details in the authentication response:
    openid.ns.ax=http://openid.net/srv/ax/1.0
    openid.ax.mode=fetch_response
    openid.ax.type.phone=http://example.com/phone
    openid.ax.type.fax=http://example.com/fax
    openid.ax.value.phone=555-1234
    openid.ax.value.fax=555-5678
    openid.ax.update_url=http://relying-party/...

3. At some later date, my OP sends an unsolicitated authentication
response containing the following data:
    openid.ns.ax=http://openid.net/srv/ax/1.0
    openid.ax.mode=fetch_response
    openid.ax.type.phone=http://example.com/phone
    openid.ax.value.phone=555-2345
    openid.ax.update_url=http://relying-party/...

How should the RP handle this update?  According to the draft spec, I
can think of two possibilities based on how "updated data" is
interpreted?
 1. the user has changed their phone number
 2. the user has changed their phone number and removed their fax number.

The first option treats the phone number as "updated data" and fax
number as unchanged data.  It seems simplest, but it isn't clear how I
would tell the RP that I removed my fax number.

The second option works on the assumption that "updated data" refers
to all the attributes originally requested.  It has the down side that
both the OP and RP now have to remember the list of requested fields
that were requested.


James.



More information about the specs mailing list