[OpenID] About Facebook, MySpace and OpenID

[Peter Williams]

Fair enough. Yes - it's a RP perspective: What it's like to deal with peers - who act differently imposing different requirements on coders. (It kills adoption.)

Can we start a conformance and 3rd party testing process like every other mature standards community, and drop a bit more of the idealism?

I don't think folks have to act gingerly any longer.

> -----Original Message-----
> From: Breno de Medeiros [mailto:breno at google.com]
> Sent: Tuesday, April 07, 2009 4:05 PM
> To: Peter Williams
> Cc: general
> Subject: Re: [OpenID] About Facebook, MySpace and OpenID
>
> This comments assumes that the Google OP is not  standard-compliant,
> which is not the case. It is rather the case that different OPs have
> implemented different standard-compliant behaviors. It maybe time to
> revisit the standard and provide more clear recommendations on
> interpretation.
>
> On Mon, Apr 6, 2009 at 12:27 PM, Peter Williams
> <pwilliams at rapattoni.com> wrote:
> >
> > It mentions the RP must store OAuth values, but says nothing of AX
> > attributes.
> >
> > This should be documented in the main API. Thanks.
> >
> >
> > Also it doesn't talk about the specifics, such as attributes you've
> never
> > asked for before (or Google doesn't support) will still be returned
> when
> > you later do ask (or Google starts supporting); or how Google
> > interprets the if_available list in terms of the user's choice.
> >
> >
> >
> > In the description of how to use AX, we have the following entry:
> >
> > openid.ext1.required   (required) Specifies the attribute being
> requested.
> > Currently, the only valid value is "email". This parameter must be
> set or
> > Google will ignore the request.
> >
> >
> >
> > In terms of "attributes you' ve never seen before" I think the better
> time
> > to change the documentation is when announcing support for additional
> > attributes. With a single supported attribute this point is mute.
> >
> >  [Peter Williams] The only think Im going to do is ask my vendor if
> their
> > openid implementation for RPs (offloading from the RP webapp)
> complies with
> > the standard (and third-party-managed interoperability accords). Im
> not
> > going to ask them: does it do Google's API, or openid through the
> Google
> > API. I will not bend my RP system to any one OP - even if they are
> AT&T (or
> > Google).
> >
> > I have no expectation of ever reading the Google API document. I have
> every
> > expectation of reading the openid documentation for RP from my
> favorite
> > websso stack vendor, which will talk to Google OP (hopefully). If it
> turns
> > out that working with Google has certain architectural implications
> on RP
> > design that are not present with other OPs, I'll probably ignore
> Google
> > (until the firm decides to follow the open standard, and nothing
> more). Now,
> > if for some reason, I *want* to have a bilateral agreement with
> Google, in
> > which my RP is all tuned up the value-add that Google OP offers above
> and
> > beyond the standard, then that's fine. I can imagine of folks wanting
> that,
> > so a bit of google  success rubs off on them. But I don't; I want
> openid
> > everywhere, vs access to google's value add..
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > general mailing list
> > general at openid.net
> > http://openid.net/mailman/listinfo/general
> >
> >
>
>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)