Re: [Trust-router] Considering delaying BOF Request

[Josh Howlett <[e-mail]>]

Hi David,

I regret that I'm a bit short on time this morning, but I'd like to
respond to some of your points particularly where these concerns Janet's
intentions and on-going work.

On 17/05/2013 08:36, "David Chadwick" <[e-mail]> wrote:
>>In the Janet pilot, there is going to be software that will make it easy
>> for anyone to run their own Janet-hosted community even if their local
>> IT department does not have a good way to make that easy.
>
>Having a Janet hosted community may be too restrictive. We need to be
>able to move to model that gives the freedom of the grid VOMS
>capability, but on an Internet scale, and without needing to run a
>separate VOMS server.

Agreed -- the hosted solution is being provided for those organisations or
communities that don't wish to operate their own Trust Router.

We certainly anticipate peering with other Trust Routers operated in the
community, subject to some kind of peering agreement that has yet to
finalised.

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

This is precisely in line with our expectations; we're describing this as
the "baseline", on which all other communities are derived.

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

I consider the UK AMF to be a community focused largely on the needs of
content provision. So it wouldn't be replaced, but rather it would be an
example of a specific community building on the baseline.

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

You would petition the CoI to include you.

>> I don't know if Janet plans to allow individual sites to advertize their
>> own COIs or not; that's a matter of how they configure filters and I
>> believe that the protocol can be made to support either approach.
>>
>>
>> The question of how the end-site trust routers get access to new COIs
>> has received some internal disagreement.  I think the current plan is to
>> flood all COIs everywhere and to make sure that in general only the
>> admin for a COI can inject routes for that COI.
>
>Given that I can get a new server now and plug it into IP, and have
>others from anywhere connect to it, means that the way IP routing works
>should be fine for TR routing, without getting overloaded. (But I leave
>you to work out the specific details for this).
>
>Having an administrator for a COI being the only person who can inject a
>new route/membership (I prefer to think about COI membership rather than
>route) into the Internet base COI is fine for small COIs, but is not
>scalable for very large scale COIs such as the base Internet CoI itself.
>There needs to be delegation of authority on a global scale to allow new
>members to be added to large scale COIs. So this should be built into
>the trust model from the outset.

Yes. This is, as Sam indicates, an area of on-going discussion. Personally
I lean towards a model whereby a Trust Router maps bidirectionally between
CoIs with equivalent policies, or unidirectionally where one is a policy
subset of the other.

>>
>> I think we'll need more and have put forward some proposals for that.  I
>> think others agree we may some day need more than that but so far it has
>> not made it onto our implementation or design priority lists.
>
>The first step is to get the model agreed at the ABFAB RFC level, then
>implementations can start.

We tried that, and failed to get traction in ABFAB. That's why we're here
:-)

We are building an implementation, as we have customers that need this
ASAP, but we will track and be consistent with whatever the IETF decides.

>  However provided
>> that the COI admin takes on the liability for incorrectly adding
>> Painless, that seems fine.  (we certainly don't want to write an APC
>> policy under which Painless would take on responsibility for COI rules
>> if Painless has never agreed to those rules.)
>>
>
>What is an APC policy?

An Authentication Policy Community; it's a type of community that makes
assertions about assurance associated with entities (e.g., how the
entities has been validated, the strength of the credential it uses to
authenticate itself, etc). We (or perhaps I :-) do not anticipate a large
number of APCs: something that roughly corresponds to DNS, something that
roughly corresponds on the contemporary Internet PKI, and something
somewhat stronger than that.

A CoI's policy will describe which APCs it is willing to trust. For
example, Janet could accredit Kent to APC1 and assert this to CoIs. This
avoids CoIs having to engage in expensive identity validation.

>>
>> I do agree with you that we'll need a trust model as part of security
>> considerations for any protocol.
>
>then we should start to write it

Definitely, any contributions would be very welcome :-)

Josh.


Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238