

![]() | Start a set with this search |
![]() | Include this search in one of my sets |
![]() | Exclude this search from one of my sets |
![]() | Permalink to these results Paste this link in email or IM: |
| Atom feed for tracking future search results Paste this URL into your reader: |
27 messages in org.oasis-open.lists.xriRe: [xri] trusted discovery workflow| From | Sent On | Attachments |
|---|---|---|
| Brian Eaton | Dec 4, 2008 8:36 am | |
| Dirk Balfanz | Dec 4, 2008 10:01 am | |
| Brian Eaton | Dec 4, 2008 11:33 am | |
| Dirk Balfanz | Dec 4, 2008 11:59 am | |
| Drummond Reed | Dec 4, 2008 12:05 pm | |
| Brian Eaton | Dec 4, 2008 2:20 pm | |
| Brian Eaton | Dec 4, 2008 4:50 pm | |
| Nat Sakimura | Dec 4, 2008 10:57 pm | |
| Drummond Reed | Dec 4, 2008 11:09 pm | |
| Ben Laurie | Dec 5, 2008 5:00 am | |
| Brian Eaton | Dec 5, 2008 7:40 am | |
| Brian Eaton | Dec 5, 2008 7:40 am | |
| Eran Hammer-Lahav | Dec 5, 2008 8:33 am | |
| Eran Hammer-Lahav | Dec 5, 2008 8:36 am | |
| Peter Davis | Dec 5, 2008 8:49 am | |
| Brian Eaton | Dec 5, 2008 9:33 am | |
| Eran Hammer-Lahav | Dec 5, 2008 9:46 am | |
| Brian Eaton | Dec 5, 2008 9:57 am | |
| Eran Hammer-Lahav | Dec 5, 2008 10:24 am | |
| Ben Laurie | Dec 5, 2008 10:53 am | |
| John Bradley | Dec 5, 2008 10:59 am | |
| Breno de Medeiros | Dec 5, 2008 11:09 am | |
| Ben Laurie | Dec 5, 2008 12:27 pm | |
| Breno de Medeiros | Dec 5, 2008 1:12 pm | |
| Brian Eaton | Dec 5, 2008 2:38 pm | |
| Sakimura Nat | Dec 5, 2008 11:01 pm | |
| Eran Hammer-Lahav | Dec 5, 2008 11:35 pm |

![]() | Permalink for this message Paste this link in email or IM: |
![]() | Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [xri] trusted discovery workflow | Actions... |
|---|---|---|
| From: | Dirk Balfanz (balf...@google.com) | |
| Date: | Dec 4, 2008 10:01:03 am | |
| List: | org.oasis-open.lists.xri | |
Hi Brian,
thanks for putting this up. A few comments:
- it would be nice if you stated explicitly what the inputs and outputs of the algorithm are. I believe they are the following:
input: (Reference R, KeyIdentifier currentAuthority) output: Reference (is Null if trust cannot be established)
- currentReference is never used inside the loop
- the terms you're defining, and the algorithm you're giving, are so abstract that it's hard to find any fault with it. So I'm going to speculate on some of the incarnations of this stuff and see whether what you're saying still makes sense.
(1) How do we get the Authoritative Key for a reference before dereferencing it? If R is some document then I can imagine that it can list the identifier of the authoritative key for the next reference in the discovery chain. But what if R is, say, the email address "bo...@foo.com". We imagine that this email address points (in some yet-to-be-defined way) to the next reference in the discovery chain (which eventually leads to the metadata about this email address). But it cannot tell us what its authoritative key is. Wouldn't it be more natural to assume that authenticated references (of which "bo...@foo.com" is not an example) are signed, and that we check whether the key used to sign them is authoritative? So you would have a procedure that, when we find an authenticated reference, goes _back_ and makes sure that the key used to sign the authenticated reference is in fact authoritative; as opposed to assuming that we can find (or at least name) an authoritative key _before_ we dereference a reference.
(2) Could we simplify the algorithm by assuming that authentication means delegation? I.e., if I don't want to delegate to a different authority, I don't sign my reference. If I _do_ want to delegate, then I sign it. And the place I'm forwarding to _is_ the authority to which I'm delegating.
Putting these two things together, how about something like this:
fuction(Reference R) returns Reference:
int MAX_ITERATIONS = the maximum number of hops you wish to follow before giving up Reference lastAuthenticatedReference = R for (iteration = 0; iteration < MAX_ITERATIONS; ++iteration) if R is Null // Discovery has failed return Null
if R is authenticated Key K = key_used_to_sign(R) if K is NOT authoritative for lastAuthenticatedReference // trust verification failed return Null
// are we done? if R has metadata of type T return R
// authentication succeeded, but we haven't found our metadata yet. // authentication means delegation lastAuthenticatedReference = R
R = followReference(R, T)
I don't know - at this point things are so abstract that it's hard to tell which one is better - but I have a feeling that it might be easier to do "if K is NOT authoritative for lastAuthenticatedReference" than it is to do "currentAuthority = nextR.delegatedAuthority"
Dirk.
On Thu, Dec 4, 2008 at 8:37 AM, Brian Eaton <bea...@google.com> wrote:
I've put a proposal for a discovery work flow that results in a trusted document on the wiki. Comments and criticism most welcome:
http://wiki.oasis-open.org/xri/XrdOne/TrustWorkflow
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php







