More detailed comments below:
On Mon, Apr 14, 2008 at 10:02 PM, David Primmer <[EMAIL PROTECTED]>
wrote:
> We're struggling with these implementation details right now. I'd love
> to see what others have decided on.
>
> quick summary of the proposed url system (just for the people api)
>
> /people/{uid}/all -- Collection of all people connected to user
> {uid}
> /people/{uid}/friends -- Collection of all friends of user
> {uid}; subset of all
> /people/{uid}/{groupid} -- Collection of all people connected to
> user {uid} in group {groupid}
> /people/{uid}/all/{pid} -- Individual person record.
> /people/{uid}/sel -- Self Profile record for user {uid}
> /groups/{uid}/self -- Collection of groups owned by the
> user, which always contains 'all' and 'friends' and may contain more.
> (Details TBD)
>
>
> We're expressing the friend graph in some of these queries but It's
> not clear from the spec how to resolve {uid} and {pid}, especially if
> they may actually be in the same underlying person data table. In the
> sample file state-basicfriendlist.xml, the user's ID's are simple
> firstname.lastname and relations to friends are through this primary
> key and the data set is self-referential.
I think we should clarify / change state-basicfriendlist.xml. My
understanding is that in real life, these IDs are supposed to be universally
unique. If that's NOT the case, somebody please scream now. I'd propose
that they be changed to something like example.org:DEADBEEF.
>
>
> contrary to this simple data set, we should assume that there will be
> some hidden primary key in the account/user data we're exposing and
> that the public name someone refers to is translated to something else
> by the service's backend. For example, your userid may be 'john.doe'
> at some social network, but the primary key on your user record in
> their database will be some other form of GUID that you never see like
> "john.doe.xyz123" in that system.
>
> "/people/{uid}/self" is the simplest pattern above but even it raises
> a lot of questions. It is the profile of the user -- uid in this case
> is the user of the application. I'll use gmail as an example system.
> "uid" here is a gmail account, [EMAIL PROTECTED] (what does the
> actual url string look like?
> "http://host.com/social-api/people/john.doe/self"; ? ). The profile is
> the profile info that the user has recorded for that account. I'm
> assuming the 'view' of this data is the full projection and the api
> would allow them to edit it.
Yep. (In the case of projected views with only a subset of fields, there
will be a <link rel="edit"> pointing at the full representation.)
>
>
> Under the covers, the john.doe user name or profile name needs to map
> to a GUID in the container's auth system. And, the request will come
> with an auth an "x-oauth-os-uid" header or parameter that includes a
> link to the GUID of the user with right to act as that user. (may be
> an admin account that can act on behalf of that user).
With OAuth, there are three possibilities:
1. No x-oauth-os-uid, and no Access Token in oauth_token: Request is being
made by a third party service, not on behalf of any particular user, and
should be interpreted/rate limited/audited/trusted accordingly.
2. An Access Token in oauth_token: Request is being made by a third party
service on behalf of a user, and the token is proof of the user's
authorization. The token may have container-specific substructure that lets
you find out what specific user authorized the request, or it may just
contain proof that an appropriate person authorized it. You may not get a
source {uid} in other words.
3. An x-oauth-os-uid, and no Access Token: Request being made by a third
party service on behalf of a user, and it's telling you the uid of the user
explicitly. You have to trust the third party service to have consulted
with the user and gotten their implicit (via TOS) or explicit consent, but
the bottom line is that you have some level of trust that lets you accept
the {uid}.
In only one of these situations do you have a requestor {uid} guaranteed to
be available. In general you don't need it; a container should provide an
implementation of an authorization check interface and the common code just
needs to honor the results.
We _might_ want to allow a special value -- like @me -- for {uid}. But it
would only be a slight convenience I think.
> In this
> scenario, it seems that even if we have a GUID for the authorization,
> we still need to be able to deterministically look up "john.doe" in
> the backend. Or, is it true that {uid} above can be very loose as the
> actual identity of the user of the app will come from the auth
> context?
{uid} should be deterministically unique.
>
>
> And just to dip my toe in the grammar of the urls,
> /people/{uid}/all/{pid}, which is an individual person record who is
> associated with {uid}. I'd assume that in a situation where the url is
> "http://host.com/social-api/people/john.doe/all/john.doe";, we'd be
> looking up "john.doe" (the one on the left side of the "all") first as
> a primary user of the container and then looking in the collection of
> contacts for john.doe That could include someone named "john.doe" but
> not not a full member of that particular container (the difference
> between being a gmail user and that gmail user having a contact who
> happens to be named the same as them or have their email address). In
> this case, we're not actually going into the friend graph of the local
> system but into the private contact storage of the user. (I believe
> Plaxo has this sort of distinction).
Right.
> The rules would change if we were
> on a closed system where you could only 'friend' someone in the system
> that had a uid. In that case the people/john.doe/all/john.doe wold be
> illegal. I guess the meaning of these relations isn't clear to me, nor
> is how much of this shindig needs to codify.
I'm not sure why this would be illegal?
>
>
> davep
>
