Hi Sam,
On 1 apr. 2012, at 09:45, "Sam Hartman" <[email protected]> wrote: > > 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. 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.... > > 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. 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 _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
