Re: [rest-discuss] W3C Note - User Agent Authentication FORM elements
- On Tuesday 04 March 2003 01:52, Chuck Hinson wrote:
> Tyler Close wrote:So how important is application security to you and others on this
> >Switching to capabilities improves your GUI, your application
> >design and your security.
> I'll take your word on the security bit. I'm not convinced of the other
list? Are there people on this list that implement business
applications, or is it mostly open use applications?
I request that the list owner open a poll on this question: "I am
currently implementing a web-service that provides access to a
business process. yes/no".
> So then, I don't understand your comment from an earlier message:Often, access control does not make sense for a shared, read-only
> <quote>... you're right, you wouldn't use this model to give everyone
> their own URI to a single, shared, read-only resource. </quote>
> As far as I am able to observe, an awful lot of the web consists of
> shared, read-only resources. Are you saying that access control isn't
> necessary for shared, read-only resources?
resource. To answer the question, you have to study the situation
to determine the roles of the participants.
In order for shared access to be an access control problem, it
must be the case that *all* participants want to protect access to
the shared resource. If any participant does not care about
protecting access, the access-control mechanism is without
meaning. This is the case in the WSJ example.
When only a subset of the participants wish to protect access to
the shared resource, the problem is a DRM problem.
Typically, access to a shared resource is only an access control
problem when the shared resource is modifiable. It is rare for a
modifiable resource to be shared between more than two
> A more useful example would be something likeAh, but that's not the question I asked you. Can you post a
> With http auth, I can give this URL to everyone who has an account at
> the bank, and that URI means the same thing to all of them - the page
> that shows the viewer the last 20 entries in their savings account
traversable link to an entry from *your* account history?
> Note that I'm not suggesting that this is a good solution for accessingTelling someone how to access their own resource is also easily
> bank accounts - it just illustrates the idea of a public, sharable URI.
> My understanding of the capability model leads me to conclude that I
> can't do anything like the above because every user would have to have
> their own URI.
done in the capability model. Using the graph that defines the
structure of the web of resources, you can determine what path
they need to follow. So, in a capability solution, you would say:
"Starting from your main account page, follow the path:
'savings/register/'." Using my web-calculus solution, you would do
this by appending the query string "?path=savings/register/" to
the main account page URI.
> >The point of access control is to create private webs ofI think you are still thinking about DRM scenarios. As I said
> >resources, with finely controlled links between them. Capabilities
> >are an excellent tool for implementing this.
> I dont disagree. But it appears to me that the private web that is
> created is only useful to one individual. What about groups of people?
> If the answer is that everyone in the group shares the same, private
> URI, then how do I revoke access to just one member of the group. (I
> suspect your answer to this is going show that I don't understand the
> capability model after all.)
above, it is rare for a modifiable resource to be shared between
more than two participants.
When you want to have revokable access to a shared resource, you
do give each participant a unique URI for the shared resource. To
revoke access, you revoke just the corresponding URI. This is no
more complex than managing an ACL for the resource would be.
> >>As a result, you've lost the ability for people to connectDoes your bank account have a separate ACL for every addressable
> >>those resources together in new ways to create new things on the web.
> >Exactly the opposite. What you've done is empowered people to
> >securely connect those resource that they want connected. The ACL
> >model prevents this.
> >Just as an example, why don't you post to this list a link to a
> >withdrawal record from your online bank account. With the current
> >interface, this is not possible: you can't do it without also
> >posting the password for your entire account. If your bank account
> >was implemented with a capability-based security model, posting
> >the withdrawal record link would be no problem. Capabilities
> >enable you to create links. ACLs prevent you from creating links.
> I'm not sure why. Assuming the withdrawal record has a URI, I dont see
> why I couldn't do that using a non-capability-based solution. (I've
> also just realized that we're probably using the word _link_ differently.)
resource? Are you allowed to modify those ACLs? Are you allowed to
introduce new principals into the ACL system? Are you allowed to
delegate all of this authority to others? Typically, the answer to
all these questions is 'no'. To support linking, all these
questions have to be answered 'yes'. An ACL design becomes far
too complex when it tries to answer 'yes' to all these questions.
When the application becomes this complex, it becomes a playground
for crackers. A capability security model supports fine-grained
linking with minimal complexity.
> >>So how do you establish an initial context (or whatever its called) in aAre you asking how a new user gets added to an existing
> >>capability-based system without doing authentication?
> >Your initial context is whatever set of URIs you start with. If
> >your program is an XSLT stylesheet, your initial context is the
> >set of URIs in the input XML document.
> But how do I (as a client) get that initial set of URIs without
> participating in some kind of authentication process? What do I click
> on (or reference) to get started?
application? If so, the first URI is given to the new user in much
the same way as a username/password is given to a new user.
> Ok - I guess I meant an example of how you would solve it. What doesIf you want a fully worked out example, I suggest something
> the URI namespace look like? How do you navigate among the various
simpler, like the tradeable credit example in the web-calculus
The schemas for all the resources used in this example can be
> >Access control is about controlling what authority you hand out.I agree that most people don't know the first thing about
> >DRM is about controlling how people use authority they have
> >already been given.
> I wont contest your definition, but my impression is that most people
> dont use that definition (rightly or wrongly).
software security. I blame this mostly on the complexity of
existing software security solutions. I think the simpler
capability security model could change the status quo.
> Controlling access to aActually, that's just a product of access control. Access control
> Resource (the R in URI) is about determining whether or not you are
> allowed to perform an operation on that resource - are you allowed to
> perform a GET/PUT/POST/DELETE.
is about how you came to have the authority to perform a
GET/PUT/POST/DELETE, how you exercise that authority, and how you
delegate that authority to others. This is a subtle but very
important distinction. The difference has caused great confusion
and error for many people, even some very smart people.
> Which brings me to another question. I understand that you control whoOne of the main design principles in capability-based security is
> can access a URI by controlling to whom you give the URI, but how do you
> control how they access the named resource. That is, how do you control
> whether or not they can POST vs GET?
that distinctions in authority be reified as different resources.
If POST and GET provide different kinds of authority, they should
be different resources, accessed through different URIs.
This means that GET on a POSTable resource should only provide
information about what to POST. GETing the results of POSTing
should be a different URI. This means you've got one URI that
provides read-access to the current state of the resource, and a
different URI that provides the authority to modify the state of
the resource. Most existing web-applications are already designed
- S. Alexander Jacobson wrote:
> I'm sorry. I was waayy too strident (too littleI don't believe it is. The identity of a thing shouldn't be coupled to
> Anyway, the question remains: Is it RESTful for
> resources to be parametrized by authentication
any Access Control List information I have about that thing.
Another reason: try to write RDF statements about a bank account, where
that bank account is identified in a relative way.
Relative ID: http://example.bank.com/account
You can't write anything about that account because to truely identify
it, you need ACL information. And in the HTTP world, the authentication
is done outside the URI.
If you had an absolute ID for a bank account, then you can actually say
things about it.
Absolute ID: http://example.bank.com/account/12345
Then, this becomes possible (in RDF):
You can't do the above w/ the Relative ID. All the RDF statements would
end up saying that *everyone* owns account http://example.bank.com/account.
This is all true, because HTTP's authentication is done at the protocol
level, and independent of the URI. The ID of the thing you are trying
to operate on is not affected by any ACL information.
Now, having said that, this is a perfectly valid Absolute ID:
But, of course, not as friendly w/ some caches and search engines. And,
you still have to supply a password (or some authenticating token).
Hope that helps,