Re: Webfinger for Gmail: availability of more structured description ? (i.e type != "text/html"?

[Joseph Smarr]

[+portablecontacts]

Yes, we were just talking about that this week, in fact! I think the plan is that rather than just returning the google-wide PoCo URL for everyone's webfinger (i.e. http://www-opensocial.googleusercontent.com/api/people/, to which you'd normally append /@me/@self to get the user's own profile, but only after doing the OAuth dance with that user), we'll return a user-specific PoCo URL (e.g. http://www-opensocial.googleusercontent.com/api/people/1234567 for a user with user-id 1234567, to which you'd only append /@self and could get public data without doing an OAuth dance, or also hit after doing an OAuth dance to get private data too). 

The only question in my mind is how best to communicate to webfinger clients that essentially this PoCo url "already has the @me part baked in"--do you think we need a separate URI in the discovery document for "PoCo URL with the @me part baked in" vs "PoCo URL without the @me part baked in"? Or maybe we should just return the user ID as a separate piece of data in the webfinger response, and clients should just know to take the global PoCo endpoint and append the user ID they find in place of the @me slot to get public data?

Let me know if you have opinions on the right way to manage this! In the meantime, I'll work on at least making sure that however you come to know to hit the right user-specific PoCo endpoint, you can get public data back without any authentication required.

Thanks, js

On Sun, Feb 21, 2010 at 1:51 PM, DeWitt Clinton <dcli...@gmail.com> wrote:

Yeah, that's definitely the idea.  I think our PoCo endpoint will need to change to include the user identifier in the URL, so that non-authenticated requests can get the public data for that user.

Joseph is working on this as we speak, I believe.

-DeWitt

On Sun, Feb 21, 2010 at 1:40 PM, Kevin Marks <kevin...@gmail.com> wrote:

Part of the point of oauth is that you can reveal the public part without auth and signal with the auth:  header that more is available

On Feb 21, 2010 1:33 PM, "Brad Fitzpatrick" <brad...@google.com> wrote:

[+poco people]

I guess that's the endpoint to which you'd perform the OAuth dance to get the user's full addressbook in PoCo form.  But I suppose we should also have a URL for the user's self PoCo record, at least the public/unauthenticated form.  Not sure what that URL is, but we should advertise it....

Chris, Joseph, .....?

On Sun, Feb 21, 2010 at 11:06 AM, Pete Warden <search...@gmail.com> wrote:
>

> Ah, missed that...

[Chris Messina]

Could we just redirect:

http://www-opensocial.googleusercontent.com/api/people/1234567

to:

http://www-opensocial.googleusercontent.com/api/people/1234567/@me

as the default behavior?

Chris

--
You received this message because you are subscribed to the Google Groups "PortableContacts" group.
To post to this group, send email to portable...@googlegroups.com.
To unsubscribe from this group, send email to portablecontac...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/portablecontacts?hl=en.

--
Chris Messina
Open Web Advocate, Google

Personal: http://factoryjoe.com
Follow me on Buzz: http://buzz.google.com/chrismessina
...or Twitter: http://twitter.com/chrismessina

This email is:   [ ] shareable    [X] ask first   [ ] private

[John Panzer]

I'd prefer two rel values, one for a PoCo service where part of the
protocol is adding the user id, and another for the webfinger target's
specific profile. Then you can also link to the latter as a
rel-alternate of the HTML version too.

On Sunday, February 21, 2010, Pete Warden <search...@gmail.com> wrote:

> On Sun, Feb 21, 2010 at 3:30 PM, Joseph Smarr <jsm...@gmail.com> wrote:
>
>
> The only question in my mind is how best to communicate to webfinger clients that essentially this PoCo url "already has the @me part baked in"--do you think we need a separate URI in the discovery document for "PoCo URL with the @me part baked in" vs "PoCo URL without the @me part baked in"? Or maybe we should just return the user ID as a separate piece of data in the webfinger response, and clients should just know to take the global PoCo endpoint and append the user ID they find in place of the @me slot to get public data?
>

> From my client's PoV, it's fine to get back a URL that requires some extra work to turn into an API call. We'll already need something like
>
> if (rel===HCARD)
> <hCard specific processing>
> else if (rel===PORTABLECONTACTS)
> <PoCo specific processing>
>
> so I don't think you lose any flexibility by documenting that in portablecontact's case you need to fiddle with the href url to turn it into a valid API call, as long as the webfinger providers are all consistent. I wouldn't like to return the user id as a separate component; at the moment the code's simple because the only values I need to extract from each link are the rel and the href.
>
> Chris's suggestion of redirecting the bare URL to @self seems nice too, it would allow naive clients to do what they do for the other unauthenticated APIs, call the bare href and parse the result.
>
> cheers,
>             Pete
>
>

--
--
John Panzer / Google
jpa...@google.com / abstractioneer.org / @jpanzer

[Joseph Smarr]

I assume you mean http://www-opensocial.googleusercontent.com/api/people/1234567/@self since the 1234567 is taking the place of the @me? We could, but normally the default target in PoCo is /@me/@all (i.e. the user's address book, not their personal profile), so I'm not sure that's a good idea. Generally, I think this stuff needs to be explicit enough that client libraries have a hope of pointing at arbitrary webfinger/XRD/PoCo endpoints and being able to discover and perform the right behavior to get the desired output, hence why I'd like to see more discussion on the "right" way to do that here...

Thanks, js

[Chris Messina]

Ok. Perhaps John's proposal for two rel values is sufficient?

Chris