[OpenID board] upcoming Google announcement regarding OpenID

Eric Sachs esachs at google.com
Fri Jul 10 00:10:26 UTC 2009


>> The idea of trying endpoint #2 first, and then failing back to #1 should
NEVER be proposed or encouraged.In a publicly documented standard, I agree
with you.

However, whitelists are common in actual practice.  We see them today in the
consumer space, though the eventual goal is to minimize that approach.  In
the case of Google Apps, most of the interest in this feature has come from
SaaS vendors who are developing products that ONLY work for existing users
of Google Apps, and that also require using the hybrid OAuth/OpenID
integration with Google to access our APIs.  So by definition, the only
IDP/OAuth-SP they can "trust" is Google Apps.

>> The other thing that concerns me is how close we are to having a
committee draft of XRD.
We haven't formally announced it yet :-)  We keep delaying internally, but
at some point we'll have to launch it and I would be surprised if we can
hold off for longer then a few weeks given how many months we have already
delayed.  But when the drafts get finalized, we're hoping to support it
within a small number of days and remove documentation for the
proof-of-concept approach.  The partners we have already worked with have
read the warnings in our documentation that we will be switching the
discovery mechanism once the standards gets solidified, so they are prepared
to have to make that change on their side.


On Thu, Jul 9, 2009 at 4:21 PM, Will Norris <will at willnorris.com> wrote:

>
> 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
>
>
> _______________________________________________
> board mailing list
> board at openid.net
> http://openid.net/mailman/listinfo/board
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-board/attachments/20090709/e0607ffe/attachment.htm>


More information about the board mailing list