[OpenID board] upcoming Google announcement regarding OpenID

[Will Norris]

On Jul 9, 2009, at 1:16 PM, Eric Sachs wrote:

>> So it sounds like this was actually intended to go to the board- 
>> private
>> list, but since it is public I'm going to throw in my two cents.
>>
>
> Feel free to discuss it on the main mailing list.  The discovery  
> discussions
> are not meant to be private.
>
> I recently posted a pointer in such a thread that says
>
> For nitty gritty details, see
> http://sites.google.com/site/oauthgoog/fedlogininterp/openiddiscovery

okay, that is helpful.  The only thing linked to in your post was a  
document on a google group that I couldn't access.  This looks very  
familiar, because we talked about this in depth on various XRI TC calls.


>> But if the relying party is unable to discover an OpenID provider  
>> through
>> normal discovery means, they make an API call to Google asking if  
>> Google
>> hosts OpenID services for that domain
>>
>
> The doc above has more details, including defining a way for a  
> domain who
> outsources their IDP (or RP in the case of someone like Janrain) to  
> publish
> a single simple file pointing to that SaaS provider.  An RP could also
> choose to pole the SaaS providers directly, but that is a policy/UI  
> decision
> for them, and by definition that type of one-off doesn't seem like  
> it could,
> or needs to be, standardized.


The document you mention all but actually recommends that approach:

> There are two locations where the host-meta document might be found:
>
> (1) http://example.com/host-meta
> (2) https://www.google.com/accounts/o8/host-meta?hd=example.com
>
> Google's endpoint will return a 400 on endpoint (2) if the domain  
> provided has not outsourced OpenID IdP funcionality to Google. So  
> one possible strategy for an RP could be to first try endpoint (2),  
> and if that returns a 400, try endpoint (1), and if that doesn't  
> yield anything, give up. Other strategies (fetching both endpoints  
> in parallel, for example), are possible.


The idea of trying endpoint #2 first, and then failing back to #1  
should NEVER be proposed or encouraged.  Quite the opposite, it should  
be strongly discouraged.  It's language like this that make this feel  
like a vendor-specific approach that the OpenID Foundation should have  
nothing to do with.  RPs should be instructed to ALWAYS attempt #1  
first, otherwise the domain owner is no longer in control.


>> But the more concerning matter is that the OpenID Foundation is being
>> asked to endorse one specific vendor as THE fallback for OpenID  
>> discovery.
>>
>
> Sorry if it sounded like that is what we I was suggesting.  I was  
> suggesting
> the OIDF could be supportive of the "approach" we are taking of  
> working with
> the community these last 6-9 months to establish standards for these  
> types
> of use cases.  Even our documentation specifies that the current
> implementation is just a proof-of-concept for how to do discovery  
> when a
> SaaS provider is involved, and describes a method that does NOT  
> require "one
> specific vendor as the fallback for OpenID discovery" though I agree  
> some
> RPs may choose to do one-off polling of a few SaaS providers.

The other thing that concerns me is how close we are to having a  
committee draft of XRD.  Admittedly, no we're not there yet.  And part  
of that delay has been because we're making sure that we have a  
solution that all involved parties can live with, including Google.   
But I get a bit frustrated when Google claims to be supporting the new  
standard (and I'll be the first to say how valuable their input has  
been), but appears to be putting all their resources behind an  
incompatible approach to the same problem... one that I'm afraid will  
only lead to great confusion[0] if it gets any kind of widespread  
adoption.  If Google wants to throw it out there as a possible stop- 
gap solution their customers can use until the next version of OpenID  
Discovery is written, that is fine.  But I just don't believe it's the  
kind of approach the foundation should be endorsing when we're so  
close with XRD.

-will