Re: [Trust-router] Considering delaying BOF Request

[Sam Hartman <[e-mail]>]

>>>>> "David" == David Chadwick <[e-mail]> writes:

I've read Josh's responses; I want to take a slightly different approach
in responding here focusing on the protocol; on the moonshot-community
list I'd focus on the pilot.

    David> Having a Janet hosted community may be too restrictive. We
    David> need to be able to move to model that gives the freedom of
    David> the grid VOMS capability, but on an Internet scale, and
    David> without needing to run a separate VOMS server.

It would be valuable if you'd write up this use case including
 requirements as an internet draft.
I think that would be very useful in the trust router BOF context.


    David> Why do I think a Janet hosted community too restrictive?
    David> Because I might want to set up a COI containing people from
    David> Europe, Australia and China who I work with. So their IdPs
    David> will need to join the community.

So, when I say Janet-hosted community I mean that  the routes in that
community will be injected by Janet-controlled trust routers.
Regardless of who injects the routes, routes to any IDP can be injected.

    David> So we need an Internet wide base community that provides
    David> generic interconnectivity at the federation level between all
    David> IdPs and SPs, in much the same way that IP does at the
    David> network level. Then any and every specialised community of
    David> interest can be built on top of this. The 

Yes, but we were talking about how to manage communities of interest.
The base community is an APC (authentication policy community), not a
COI.

You're absolutely right that for scaling reasons some APCs will require
delegation.
The base APC is definitely such.

It's possible some large COIs will require this as well.
I've been unable to find a use case for a COI that required distributed
management, but I agree the protocol should support this.



    David> Janet community
    David> would be one such community, which could be used to replace
    David> the UK AMF. So a Janet hosted community should not be the
    David> base, but rather a specialised academic CoI on the base.

You're mixing several things here:

1) The base APC. We agree that the base APC should not be hosted, but
instead various parties will inject routes.

2) A Janet hosted community. This can be about anything and contain any
members.  The interesting point is that Janet injects the routes.

I think we agree that the protocol needs to support hosted communities.

3) a community that janet uses for organisations in the UK.  This could
be janet-hosted or otherwise.  i think we agree that this is distinct
from the base APC.


    David> So this brings up one other requirement. How can a researcher
    David> such as myself, add an SP to the Internet base community so
    David> that it can be subsequently configured to trust a specialised
    David> COI? I can do this now at the IP level, but not at the
    David> federation level.

Agreed.
the protocol supports this.
determine whether a SP is in an APC with respect to a given IDP is
somewhat different than determining whether that SP is in a COI with
respect to an IDP, but there are approaches for both.

    David> Having an administrator for a COI being the only person who
    David> can inject a new route/membership (I prefer to think about
    David> COI membership rather than route) into the Internet base COI
    David> is fine for small COIs, but is not scalable for very large
    David> scale COIs such as the base Internet CoI itself. 

I recommend that you think about it in terms of routes rather
than memberships.
Not all parties will have the same policies about who to trust, and
partitioning and other affects can cause the topology to appear
different at different points in the system even if policy is uniform.

Thinking of things as memberships seems like a convenient
simplification.  For myself, I've found that when I make that
simplification my reasoning tends to jump over details that actually
matter in terms of coming up with design or security analysis.


    David> There needs
    David> to be delegation of authority on a global scale to allow new
    David> members to be added to large scale COIs. So this should be
    David> built into the trust model from the outset.

if you replace COI with community I'll agree with you.
As i said, the use case for this is clear for APCs. It's not clear to me
that it is true for COIs, but I see no harm in supporting it.

    >> Why do you think that it's important that Painless's trust router
    >> believe that it's in a COI?  What's wrong with Painless being
    >> co-opted into a COI?

    David> Because you would not want me to co-opt you into my Down With
    David> Russia, Abolish Corporation Tax for Multinationals, and
    David> Polygamy for All COIs would you, without your agreement? 

The key in that statement is that it's your community.
If you want to make ridiculous statements about me, the problem comes in
when someone trusts those statements.
I'd recommend than no SPs use your community if you're going to do that
sort of thing.

non-technical measures such as law may give me recourse if I find your
statements objectionable rather than simply ridiculous.
The Internet has many ways for people to group things together already.
I see no harm in you creating a useless group that includes me.

I see significant harm in someone inappropriately trusting that
grouping.

it seems    David>  It seems reasonably harmless to me provided that Painlessl
    >> does not use an attribute release policy more liberal than what
    >> it would use with an unknown service.

    David> Well for privacy protection reasons it should not release any
    David> personal information to an unknown service. 

I agree that  people concerned about privacy should disclose little
(probably nothing) to an unknown service.
In this case, the IDP will almost certainly need to know about
communities it is part of.
i don't see why it needs to be the trust router rather than the IDP
though.