In a previous article, I bemoan the pain of writing an OpenID Relying Party that wants to fetch user attributes from their OpenID Provider, because of the at least 4 ways in which those attributes must be requested. And then later I promised that DotNetOpenAuth would offer help to alleviate that pain. That help has come. It actually came way back on June 26, 2009. But only now did I officially document that help.
Introducing the AXFetchAsSregTransform “behavior”, which is now fully documented on the project wiki site. I’ve spent some time recently (and will spend more in the near future) documenting the common scenarios that people have questions about, and since it is on the wiki instead of only on this blog, it will be more likely to be updated as new versions of the library come out.
The AXFetchAsSregTransform behavior makes it so that all you have to do is work with ClaimsRequest and ClaimsResponse – no matter what Provider you’re talking to. If the Provider only supports AX, it Just Works because the special behavior will automatically translate your sreg request into an AX request, and then translate the response back from AX to sreg. Woot.
Is it working only with RP?
What about OP?
And, any example of working with SREG/AX on provider's side?
Constructor of ClaimsReponse is internal, I can't create it's instance.
Hi Derigel,
Yes, this helper class works on the OP side as well as the RP side. ClaimsResponse' constructor is internal, as you say. You should create an instance of this class using ClaimRequest.CreateResponse()
Huge. I wish JanRain OpenID Enabled also had something similar.