[OpenID] AX implementations
Shane B Weeden
sweeden at au1.ibm.com
Fri Sep 25 22:48:24 UTC 2009
Allen,
Thanks for your response.
> Which OpenID 2.0 OPs support SREG only?
Verisign is one (pip.verisignlabs.com). At least it's not advertised in
xrds.
> Unfortunately, in practice, SREG seems to work a lot better, since it's
more compact (AX responses are very verbose, and often cause the response
to exceed browser URL length limits) and SREG also has a standard schema.
Mostly agree, although implementations may just switch to POST per the spec
when messages get long, and this seems to work ok for me. What I wanted to
see (and previously posted about with little support) was this change to
the SREG 1.1 draft spec to allow SREG to be extensible. In section 4
change:
A single field MUST NOT be repeated in the response, and all included
fields MUST be taken from the set of fields defined in this specification.
to:
A single field MUST NOT be repeated in the response.
Then SREG is "legally" extensible and lighter weight and easier to use. My
own implementation does not enforce this unnecessary restriction and I have
found extensible SREG useful in my own deployment scenarios (sure, they
could just as easily use AX with custom schema, but for all the reasons you
point out SREG is more efficient).
Cheers,
Shane.
Allen Tom
<atom at yahoo-inc.c
om> To
Shane B Weeden/Australia/IBM at IBMAU,
09/26/2009 06:37 openid-general at lists.openid.net
AM cc
Subject
Re: [OpenID] AX implementations
Shane B Weeden wrote:
> Does anyone out there actually use the store_request and store_response
of
> AX 1.0?
>
I have not seen this in the wild. Most OPs that allow write access to
the user's data would probably use proprietary APIs that are OAuth
protected, and use the OpenID OAuth Hybrid Extension to pass the OAuth
credential to the RP.
That being said, there are many shortcomings with this approach.
- Many developers find it difficult to make OAuth API requests,
especially generating OAuth signatures
- Custom code needs to be written for each OP, since none of the APIs
are standardized
- There's no standard way for the user to view, approve, and edit the
data inline before it's posted to the OP
- OAuth credentials are independent of the user's authentication session
at the RP and the OP, meaning that the user can sign out of both the RP
and the OP, and the RP is still able to push data back to the OP
> I can see some value in using AX as a replacement or extensible
alternative
> for SREG, and can see several public OP's support AX (though more support
> SREG only),
Which OpenID 2.0 OPs support SREG only? Yahoo used to support SREG only,
and but now we support both. Unfortunately, in practice, SREG seems to
work a lot better, since it's more compact (AX responses are very
verbose, and often cause the response to exceed browser URL length
limits) and SREG also has a standard schema.
> but is there really anyone supporting store_request?
>
I'd really like to see this.
> Which OP in their right mind would even let an RP (other than a
whitelisted
> RP I guess) store attributes.
>
I can't really think of any realistic use cases where an RP would want
to update the user's SREG attributes. While I can imagine some
hypothetical cases where the user would want the RP to update the user's
name/gender/email address/zipcode, but none of them seem all that
plausible.
However, there is very valuable case where the RP would want to send
user activities back to to the OP to be syndicated to the user's
contacts. For instance, if the user uploaded some photos onto the RP's
site, the RP may want this event to be syndicated back to the OP to get
referral traffic. Potentially, a lightweight interface using AX's store
request can be standardized to syndicate Activity Streams.
Allen
More information about the general
mailing list