On 17/12/2014 18:06, Dave Cridland wrote:
OK, I entirely forgot about that. And in fairness, I think Section 6 is
reasonable; I think Sections 4 and 5 are the problem.
Ok, it become more precise, I'll work on it
This document is not about building an external PEP service; this
document - or at least sections 4/5 of it - is about access control.
right
In this case, as I wrote, every PEP node already has an access-model,
and applying a different access model based service-wide around the iq
type is clearly both duplicating the access control of PEP, and making
it worse, and failing to interact properly.
PEP node is a restricting access model, not something used to give more
access (or privileged as called in the protoXEP), it is definitely not
the same thing as PEP access control.
Well, that's sort of the problem - the protocols are already defined on
a per-extension basis, and you've applied a generic solution across the
top. The two just don't fit.
What I mean is if you want to give access to a feature, in XMPP terms
it's a XEP (and an associated namespace). As you mentioned in a former
email, XEP have not a consistent model once in the <query> par of <iq>
stanza. So how can you give an generic attribute based access control,
if XEP are organised in all different ways ? You can explicitly mention
XEP by XEP how to do, but that's not generic anymore, and need to be
updated when new XEPs appear.
I really think it's worth addressing just the immediate requirements to
begin with.
The whole XEP address the immediate requirement, except maybe the
"client mode" part which is a "bonus".
Like the roster access-model already in PubSub? (I'm pretty sure M-Link
does this already for PEP nodes).
Exactly like the roster access-model already in PubSub which is
implemented nowhere (or at least, in none of the servers I have tested:
Prosody, Metronome, OpenFire, Ejabberd, which is already a good set),
except in our PubSub component.
But in Berlin summit I talked about this with Ralph Meijer, and it seems
that in fact I misunderstood and the "roster" in question in the PubSub
roster, not publisher's roster like I thought (and I need access based
on publisher's roster). So it's a model which doesn't exists yet, and
would be sort of "publisher-roster access-model". That means that before
having a valid and standard way of doing this, we need a new XEP,
discussions, etc. And before having this implemented in most of servers
we can wait... well... ages.
A client *can* manage its own PEP service, can't it?
No it can't, it can only have the PEP service implemented in its server
This protocol would
be enabling it to manage someone else's, surely?
No it wouldn't, access is restricted to the client which accepted the
privileged (see section 5.1 of the protoXEP)
Moreover, if you want
to run your own PEP service as a client, you only need the other
protoXEP, not this one.
No, the "Namespace delegation" is not sufficient, as a PEP service need
to send <message> stanza and access <presence> informations, which are
addressed by the "privileged entity" XEP in section 6. And that also
means access to roster, also addressed by "privileged entity".
I pointed out the problem with MAM, for example. I have no idea what
else is there, but there are problems with PEP as above (and Pubsub and
MUC in the same way), and MAM. I wondered about Search, and anything
involving ad-hoc is clearly a bit weird.
You pointed out that there is no granularity, but that's not a security
issue (if you give access to MAM to a component, expect it to do things
with MAM).
You're asking server administrators to understand the protocol-level
issues?
No, I'm asking administrators to understand what they put in
configuration, and which permissions they allow in a *whitelist* (as
recommended in section 11): allowing privileged on roster is something
acceptable, allowing privilege on "http://jabber.org/protocol/xhtml-im";
make no sens, you don't need to understand the protocol level to
understand that. In addition, server can have they own hard coded list
of acceptable namespaces.
But anyway, the problems basically all derive from this being generic.
Yes, the goal is to avoid to be stucked on server implementation for any
past present or future XEP.
You know you could just write a server? You needn't bother with S2S; you
can just run yours as a component into another one. PEP/Pubsub-onna-jid
is *way* harder to do than the rest of C2S, and I suspect it's actually
easier than doing all this proxying.
You mean having a server as a component ? Something like
myextraserver.myactualserver.tld ? Above the complexity of the thing, it
will just not work for PEP, the myactualserver implementation will
manage all PEP requests, and anyway myextraserver couldn't send
notification in the name of the client entity. Maybe I misunderstood
what you suggest, but I'm curious to see a working solution here.
Basically, unless you really want to do the ocean-boiling exercise of
doing this properly - and I really don't dispute that it's hard work -
then why not strip this down to just section 6 for now?
I can try to work on it anyway, just let me a couple of days to think
quietly about this and study a bit more XACML and your concerns, maybe
we can have a satisfying solution without writing an entire new thing
(and hopefully without postponing by months or years).
Goffi
