Action item from IIW: Owner attribute
Sunir Shah
Quick intro: I'm the head of integrations at FreshBooks, the leader in
online billing for freelancers, teams, and web applications; and I'm
the cat herder at http://www.thesmallbusinessweb.com, which is a 100
strong association of companies working to build the Open Web as the
best market for small business software (vs. platforms as a service).
One of the market advantages of platforms over the 'Open Web' is that
they make it easy for applications with no prior relationship to each
other to discover each other and access each other's data. The
comparable solution on the Open Web are service directories and a
simple protocol to register services into these directories. Hence,
XRD and XRD-P.
I expressed three arguments at IIW10 regarding the direction of XRD-P,
which I will express again in separate emails. In descending order of
priority
1. Services have owners
2. Services should not have to keep handles to <link>s
3. xml:id collisions should be mitigated
1. Services have owners
Problem 1.1 Service updates
One goal is to allow third party services to register themselves on
behalf of the user who owns the registry. For instance, if Joe Q.
Average starts a WordPress blog, they probably don't know anything
about XRD, but they would like to register their blog as an endpoint
to receive republishable content. Their blog software would ask them,
"Do you want to use this blog as a place to publish content from the
Web?" and if the user clicks yes, the blog software would negotiate
the registration.
Since Joe Q. Average is average, he also has a Facebook account and
Twitter account which are also reasonable endpoints for content. He
also registers these services, so he has three services registered,
all with the same type.
If Twitter changes its endpoint URL, it needs a simple way of finding
its own service endpoint and updating only that one. Moreover, it
should only update its own and not accidentally update someone else's
endpoint. Therefore there should be a way for Twitter to quickly
identify its own endpoint. Note that you should not use the endpoint
URL to key on because it could be several versions out of date.
Problem 1.2 Swizzle attacks
More problematic is the case of an attacker changing someone else's
endpoint. Imagine Alice is setting up her first online store to sell
hand puppets. She's already a PayPal customer, and PayPal is already
registered as the payment service endpoint. When she goes to, say,
Shopify to open her store, Shopify discovers her PayPal account and
she's up and running selling puppets in minutes.
Because of a national fad in hand puppets, Alice's store become wildly
successful. However, Mallory the attacker decides he wants to cash in
on Alice's success. He sets up a hand puppet community, attracts Alice
to log in and register, she does an OAuth dance to supposedly allow
the community to register its Activity Stream, and them Mallory
changes her PayPal endpoint to be his own.
A few days later, he is a faux hand puppet millionaire and living
large in Tahiti far from the long arm of net.law. Frankly, I'm
jealous.
Solution. Services should be scoped to owners.
<link/>s should be scoped to the service that registered them. They
should have owners. Only the service who owns that <link/>, the user
who owns the registry, or the organization that owns the user (e.g.
their employer) should be able to modify registered endpoints.
There is a simple, easy, and sensible way to implement this. Create an
owner attribute that stores the identity of the service. Presumably
the service is using OAuth to gain authorization to modify the XRD, so
store the Consumer Key in the attribute. Only OAuth consumers with
matching consumer keys can modify or delete that <link/>. If the owner
attribute is missing, then any consumer can modify that <link/>. It is
RECOMMENDED that XRD providers put owner attributes on all <link/>s.
I suggest the attribute name could be one of the following
* owner -- keep it simple
* dc:publisher -- "An entity responsible for making the resource
available." http://dublincore.org/documents/dces/
* dc:creator -- "An entity primarily responsible for making the
resource." http://dublincore.org/documents/dces/
I originally recommend using the Dublin Core, but I think it's
unnecessarily confusing and complicated and brings in semantics that
are confounding, but maybe someone has an opinion otherwise.
I also wonder if there may be cases where there are multiple owners of
a link? If so, the owner attribute should either be space separated
(like the HTML class element) or comma separated. If not, then that's
too much complexity for nothing.
Cheers,
Sunir Shah, Chief Handshaker, FreshBooks
(416) 481-6946 x224
http://www.freshbooks.com/team/sunir
http://twitter.com/sunir
Dobes
I suppose the owner attribute would match whatever was used for
authentication?
In that case the service has to validate or tweak the XML to set the
owner based on the authorization result.
It may be unnecessary to change the XML format but instead allow the
registry to decide how to associate links with owners along with
deciding how to authorize requests.
The spec can then be updated to describe the owner concept and that
registrants can never change each other's data but without prescribing
an implementation.
Then add some bulk update and delete operations to update or remove
all hrefs for the authorized owner... for a single user or possibly
for all users. The latter would require a more powerful registry
implementation.
On May 26, 10:31 am, Sunir Shah <su...@freshbooks.com> wrote:
> Hey folks,
>
> Quick intro: I'm the head of integrations at FreshBooks, the leader in
> online billing for freelancers, teams, and web applications; and I'm
> the cat herder athttp://www.thesmallbusinessweb.com, which is a 100
Sunir Shah
Then it could presumably survive database crashes, database outages, network splits, and caching on multiple servers (a consideration since the read:write ratio of the XRD will be 100:1 or 1000:1).
Cheers,
Sunir
Sunir Shah
Cheers,
Sunir Shah, Chief Handshaker, FreshBooks
(416) 481-6946 x224
http://www.freshbooks.com/team/sunir
http://twitter.com/sunir
Will Meyer
I for one agree with the owner proposal conceptually. And I don't
think there needs to be a multi-owner case -- whomever provisioned it
there is the owner. That argues for using creator or publisher and
not "owner", but no matter.
Is there a spec update in the nearish future? These definitely were
some items discussed of late and I think this and the similar ID
discussion could probably deserve an aggregate proposed update, at
least potential drafts we could review...
W
Sunir Shah
Cheers,
Sunir Shah, Chief Handshaker, FreshBooks
(416) 481-6946 x224
http://www.freshbooks.com/team/sunir
http://twitter.com/sunir
Jared Hanson
The spec is open, so in a certain sense, no one owns it. Going
further, this work should be licensed under the Open Web Foundation
Agreement (or similar), in order to resolve legal issues, which may
speak more directly to your ownership question.
The source from which the draft is produced is available via
Subversion and hosted on Google Code here:
http://code.google.com/p/xrd-provisioning/source/browse/#svn/spec/trunk
I originally authored the current draft and intend to update it as
discussions proceed on this group and elsewhere. I have some replies
to the group in my queue that I, regrettably, haven't found the time
to finalize and post. (I've noticed your follow ups as well. They are
suitably prompting me. I apologize for not managing my time better
with respect to this.)
I know a couple of us are also working on implementations, which I
think will be useful in revising and finalizing the XRDP spec. I
suspect that implementation will be a gating factor for a while, as it
is dependent on XRD finalization and implementation before the "need"
for XRDP is recognized.
Despite that, I think its good for those of us who recognize this need
early to have discussions and propose a solution. Thank you for your
contributions.
Jared
On Jun 22, 3:55 pm, Sunir Shah <su...@freshbooks.com> wrote:
> By the way, who "owns" the spec, so to speak?
>
> Cheers,
> Sunir Shah, Chief Handshaker, FreshBooks
> On 9-Jun-10, at 4:07 PM, Will Meyer wrote:
>
> >> Crickets...?
>
> > I for one agree with the owner proposal conceptually. And I don't
> > think there needs to be a multi-owner case -- whomever provisioned it
> > there is the owner. That argues for using creator or publisher and
> > not "owner", but no matter.
>
> > Is there a spec update in the nearish future? These definitely were
> > some items discussed of late and I think this and the similar ID
> > discussion could probably deserve an aggregate proposed update, at
> > least potential drafts we could review...
>
> > W
>
> >> Cheers,
> >> Sunir Shah, Chief Handshaker, FreshBooks
> >> (416) 481-6946 x224
> >>http://www.freshbooks.com/team/sunir
> >>http://twitter.com/sunir
>
> >> On 26-May-10, at 1:31 PM, Sunir Shah wrote:
>
> >>> Hey folks,
>
> >>> Quick intro: I'm the head of integrations at FreshBooks, the
> >>> leader in
> >>> online billing for freelancers, teams, and web applications; and I'm
Charlie Reverte SK
I don't mean to jump the gun on any spec update process, I just wanted to get a demo implementation of some of these ideas out there so we could talk in more concrete terms. I'm a little concerned over the JSON chatter in the webfinger group - I'm a fan, however I'm much more a fan on stabilizing on something we can finally use. Is anyone planning on using xrdp outside of the context of webfinger?
My goal is to get the demo implementation to the point where people can delegate to it for webfinger/xrdp services from their domains for dev and even production use.
Charlie
Sunir Shah
Thanks for the update. If you need help working on the spec, I can
certainly be of service. I don't want to step on anyone's toes,
especially since I don't have an implementation backing me up, but I
can certainly write up a section, edit it, etc.
Cheers,
Sunir Shah, Chief Handshaker, FreshBooks
(416) 481-6946 x224
http://www.freshbooks.com/team/sunir
http://twitter.com/sunir