Re: Comments on "Good Practices for Capability URLs" FPWD

On Mon, June 9, 2014 04:24, Noah Mendelsohn wrote:
>
>
> On 6/7/2014 10:22 PM, Jonathan A Rees wrote:
>> I don't think there's any point in discussing or even raising the
>> question of whether it's 'OK' to create unguessable URIs.
>
>
> On Sat, Jun 7, 2014 at 12:56 AM, Noah Mendelsohn <nrm@arcanedomain.com>
> wrote:
>
>> although there are cases where it is reasonable to gamble on having URLs
>> be kept secret, the Web is not in general designed to preserve such URL
>> secrecy.
>
> I don't see these two quotes, taken in isolation, as being in conflict
> with
> each other. I have never suggested that it's not "OK to create unguessable
> URLs. I have suggested (and Rob obviously disagrees), that we should not
> expect the Web to then protect those URLs in ways that go much beyond
> what's already called for in normative specifications.
>
> Noah
>

I don't disagree. I just believe that those normative specifications
combined with a good understanding of the security properties involved and
proper use of least authority based usage patterns, can combine to make
the use of sparse-caps the one with the lowest overall risk.

There are issues with passwords, with cookies, with federated identity
management, with single granularity access control, etc, and yes there are
issues with capability URLs, at least in the way they are commonly
constructed and used. My problem currently lies in the fact that any
statement that effectively discourages the use of capability URLs,
implicitly encourages the techniques that have their own sets of issues.

What I thus disagree with is what should be done with the 'conclusion'
that the use of capability URLs should NOT be the default. IMO the
'proper' use of capability URLs removes more problems than it introduces.
My opinion thus is that its use SHOULD be the default, but I don't
advocate any such statement be put in the draft. I think the draft should
be about the 'proper' use of capability URLs, not about capabilities
versus ACL, passwords versus sparse-caps, IBAC vs ZBAC, etc. That is where
you propose to underline this 'conclusion', I propose to simply strike it
and declare any weighing of technologies that implicitly includes weighing
competing security architectural paradigms as 'out of scope'.

Received on Monday, 9 June 2014 11:10:36 UTC