WebFinger at Google

Paul E. Jones paulej at packetizer.com
Fri Mar 26 17:16:55 UTC 2010


Santosh,

 

While I have no objection to making changes to the OpenID spec to support
Webfinger if that's what folks want to do, I don't think it's strictly
necessary.  We could just have a very brief document that explains how to
publish an OpenID identity via Webfinger and how OpenID RPs might use
Webfinger to get the OpenID identifier.  These steps happen before the
current OpenID auth procedures start, which means we could keep it separate
and fairly clean.

 

I'm somewhat in the same position as you.  I've implemented OpenID (OP side)
and I use it, but I'm not a part of the team writing or changing specs.  I'd
be happy to engage with folks to do that, but not sure who is leading the
work.

 

Paul

 

From: Santosh Rajan [mailto:santrajan at gmail.com] 
Sent: Friday, March 26, 2010 12:29 PM
To: Paul E. Jones
Cc: webfinger at googlegroups.com; openid-specs at lists.openid.net
Subject: Re: WebFinger at Google

 

Paul,

 

I can see where you are coming from, and most people will agree with your
suggestion for the rel value (even me). However I think the problem is with
the "ground realities" at the moment so to speak. There are two problems
with two solutions we have to look at.

 

1) How to integrate webfinger with the current OpenID 2.0 spec.

2) How to integrate webfinger with OpenID v.next.

 

I am not too worried about case (2). It will happen in the future and there
are a lot of competent people around here to sort that out.

 

My suggestion for looking at webfinger as "normalizing an email like
identifier for OpenID" is to allow email like identifiers to work with the
existing OpenID 2.0 spec.

 

To make webfinger work with OpenID 2.0 all we need is an addendum to the
"normalizing the user supplied identifier" section (7.2) of the 2.0 spec, as
explained in my earlier post.

 

Also we need to acknowledge that the identifier returned by webfinger is not
the claimed id, because their may be redirects.

 

Also I must acknowledge that I am not an expert on OpenID or webfinger (only
a user), and all this is IMHO.

 

Santosh

 

On Fri, Mar 26, 2010 at 8:33 PM, Paul E. Jones <paulej at packetizer.com>
wrote:

Santosh,

 

The identifier returned via Webfinger may or may not be the "claimed ID"
since it might be user-entered and not yet normalized.  However, I think a
rel value of

 

http://openid.net/identity

 

would still suffice for both normalized identifiers and those which are not
yet normalized.  The value really should be considered "user provided", in
my view.

 

Once the value is retrieved, I think it should be given treatment just like
any other ID entered into the OpenID login box.  Should a person be allowed
to enter an email address form and then return a different email address
form in the identity field, thus forcing another Webfinger lookup?  I can
see an opportunity for abuse there, so I'd prefer the disallow it, but I
could go with whatever is decided.

 

Paul

 

From: Santosh Rajan [mailto:santrajan at gmail.com] 
Sent: Thursday, March 25, 2010 6:28 AM
To: Paul E. Jones
Cc: webfinger at googlegroups.com; openid-specs at lists.openid.net


Subject: Re: WebFinger at Google

 

>From the OpenID perspective we have to see webfinger as a part of
"normalizing  the user supplied identifier". So the OpenID normalization
process would go something like this given a user supplied identifier. (I
will ignore XRI for simplicity)

1) Check to see if the identifier starts with http or https. If yes proceed
as per protocol.

2) If not check to see if the identifier has an "@" sign within the
identifier. If yes use webfinger to get the normalized identifier and
proceed.

3) If not add http to the identifier and proceed.

 

So really what webfinger returns is the normalized identifier, it is NOT yet
a "claimed id" nor is it a "Local id".

 

So I am suggesting one of these two rels.

"openid.normalizedID".

"http://specs.openid.net/auth/2.0/normalizedID".

On Thu, Mar 25, 2010 at 11:02 AM, Paul E. Jones <paulej at packetizer.com>
wrote:

Jared,


> It seems weird to return the user's OpenID identifier, when ultimately
> the OP Endpoint URL is what you need if you want to authenticate the
> user.  However, I think "http://specs.openid.net/auth/2.0/server"
> should have been used for the rel type, as it is actually defined by
> OpenID Authentication 2.0 spec for that purpose.

I don't think it's weird at all to use webfinger to return one's OpenID
identifier.  After all, Webfinger is intended to be a means of discovering
information about a person.  Once the identifier is learned, then the OP can
be discovered based on that ID.  Returning the OP URL without the user's
identifier is not as useful, since the OP would not know who is being
authenticated: it would then have to prompt the user for his identity.


> What is really needed is an agreed upon URI for what was the "http://
> specs.openid.net/auth/2.0/signon" type (which carried the user's
> OpenID URL in XRDS' LocalID element (which is gone from XRD)).

If the rel value is "http://openid.net/identity" and the href value
represents the user's OpenID identifier, then the RP knows what to do with
that.  I really think that's what we should try to agree upon.

This would minimize the additional effort an RP would have to make, just
adding a Webfinger resolution step and making no changes to the OpenID spec.
The RP might want to implement Webfinger, anyway, in order to discover
information about the user, such as his name, picture, or other information
he wants to share with the world.

Paul


_______________________________________________
specs mailing list
specs at lists.openid.net

http://lists.openid.net/mailman/listinfo/openid-specs




-- 
http://hi.im/santosh




-- 
http://hi.im/santosh



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100326/52281ad7/attachment.htm>


More information about the specs mailing list