On 06/07/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> On 6-Jul-07, at 12:37 AM, James Henstridge wrote:
> > 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?
> There is a use case for OpenID (though not very well defined) where
> the OP could send a positive assertion without identity / claimed_id
> fields (e.g. if the RP only requests the zipcode). For something like
> this, the RP may (note the lowercase may in the AX spec as well) add
> whatever identifying information it needs (not necessarily for a user
> id / account).

Fair enough.  I had not considered that case.

> > 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.
> Yes, the update uses the signature mechanism in the underlying OpenID
> message.
> > In either case, it should be ready to answer a check_authentication
> > request.
> Not entirely; the OP MUST NOT honor check_authentication requests for
> shared associations (this would allow a type of attack).

Okay.  In that case it sounds like it would be best practice to
generate a private association handle for each unsolicited response
since there is no guarantee that the RP has kept hold of its
association handle, so may not be able to verify the update if a
pre-existing handle is used.

Would that be appropriate to include in the spec or some best
practices document?

> > 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
> > [...]
> > 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.
> I don't think it's implied anywhere (or a good design) to keep state
> between the original request and subsequent updates. So the RP cannot
> infer the 'removed' statement just because an update did not contain
> an attribute that was part of the original exchange.
> The update message is a fetch response, so I think it should be
> interpreted as such by the RP: "the user has a new phone number".
> Then the RP can decide what it wants to do with the new value, as if
> it had requested the same attributes again.

Thank you for the clarification.  It seems that an OP will get the
most consistent results if it always sends all attributes in an update
then, so it doesn't need to track whether intermediate updates failed
(or track exactly which attributes were changed).

> To indicate that the user has deleted an attribute, the count=0
> mechanism can be used:
> > An "openid.ax.count.<alias>" with a value of "0" together with its
> > corresponding "openid.ax.type.<alias>" field MAY be included to
> > explicitly state that no values are provided for an attribute.

It might be worth demonstrating this in the example from section 5.2
then.  Currently it reads:

If this is a case where the user has not given their gender it should
perhaps use "openid.ax.count.gender=0" instead.

specs mailing list

Reply via email to