Subject: Re: [abfab] Trust router work

From: Sam Hartman <[email-masked]>
Date: Sun, 01 Apr 2012 03:44:59 -0400

There were some discussions after the meeting.
Klaas suggested defining the problems in terms of the two that came up
in Alan's discussion:

1) B shares credentials with A and C. A would like to talk to C.

2) A would like to be able to discover a set of introductions to talk to
some realm Z.

Those two problems are not sufficient to interest me. If all I got were
solutions to those, I would not be able to meet my customer
requirements.

The wording above implies  somewhat of an anti-PKI bias. For those two
problems that is because I couldn't come up with a clear
technology-neutral statement in 30 seconds or less.

However it's a starting point for a direction. I'd like to thank Klaas
and Alan for getting us this far.

It's going to be a bit before we get back to the problem statement because we need to focus
on the base specs and because at least within the Moonshot context we
need to flesh out our solution more.

---

From: "Klaas Wierenga (kwiereng)" <[email-masked]>
Date: Sun, 1 Apr 2012 11:38:49 +0200

Hi Sam,

> technology-neutral statement in 30 seconds or less.

Ehm, I don't understand the wording about anti-PKI, I don't read that in it. But to reiterate my point, I really think we need to understand the problem before assessing the solution. If we were able to cut the problem up in smaller problems that would make for a good divide and conquer approach. 
It may be my lack of understanding of the problem you are trying to solve, but I had understood it in terms of finding a "trust path" between 2 arbitrary entities and getting an introduction to the next hop on that trust path. I am thinking about it in terms of a path in a graph.

- A wants to talk to Z, A has a trust relation with B
- A discovers a path A, B, C, D, ..., Z
- A asks B for an introduction to C
- A asks C for an introduction to D
....
- A gets an introduction to Z from Y

So I see basically 2 approaches to that problem:

A) find all paths between vertices A and Z and then for all of these paths try to establish trust between any  2 connected vertices 

B) the edges between any 2 vertices denote an existing trust relation, so the problem consist of finding a path between vertices A and Z

Both approaches are pretty much standard graph problems.... so I must be missing something....

> need to flesh out our solution more.

Then let's start with the Moonshot context and see how that is not captured by above clauses, perhaps we can generalize from that. It seems bad design practice to work out a solution to an unknown problem.......

Klaas

---

From: Alan DeKok <[email-masked]>
Date: Sun, 01 Apr 2012 12:34:58 +0200

> solutions to those, I would not be able to meet my customer

  I'm presuming that they're part of the solution.  If so, what *else*
is required?

> need to flesh out our solution more.

  I'd like a clear problem statement.

  From what I've seen of your requirements, you want the ability to have
multiple "groups".  What you call communities of interest.

  i.e. a realm is tied to a specific home AAA server.  But that realm
can exist in different contexts, and have different routing properties.

  e.g. foo.edu belongs to eduraom, but ALSO has a commercial agreement
with a roaming provider.  It wants to inject different routes into those
two different routing fabrics.

  If that's true, then the first points you raised are only steps 1 and
2 of the solution.  Step 3 would be to have a registrar which would
coordinate group membership.

  I think the confusion for me is that I don't see why additional
complexity is needed.  Roaming operators already do roaming by realm, in
a particular context.  e.g.  "example.com gets routed through the
wireless broadband alliance"

  For me, it looks like step (3) is widely deployed.  That's why I'm
interested in talkiing about steps (1) and (2).

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 02 Apr 2012 06:14:06 -0400

>>>>> "Klaas" == Klaas Wierenga (kwiereng) <[email-masked]> writes:

To clarify, I think the next step on this space for me to take in the
ABFAB context is to explain what the above two problems don't capture
from my customer requirements. That is to say what additional problems
I'd need to solve to build a system that I believe people might want to
deploy.

It's going to be a while before I get to that.
There are ABFAb base spec issues and limited time on my part that will
get in the way.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 02 Apr 2012 12:51:16 +0200

On 04/02/2012 12:14 PM, Sam Hartman wrote:
> To clarify, I think the next step on this space for me to take in
> the ABFAB context is to explain what the above two problems don't
> capture from my customer requirements. That is to say what
> additional problems I'd need to solve to build a system that I
> believe people might want to deploy.
> 
> It's going to be a while before I get to that. There are ABFAb base
> spec issues and limited time on my part that will get in the way.

Thank you for your summary Sam. I think your priorities are the right
ones.

	Cheers Leif

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Tue, 03 Apr 2012 07:39:08 +0200

> Thank you for your summary Sam. I think your priorities are the right

In the meantime, there is a potential use case in a project I'm involved
in. If I manage to move the idea forward, I'll keep the list updated.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx